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Description 

RELATED APPLICATION 

[0001] This is a continuation-in-part of U.S. Patent 
Application Serial No. 08/726,262 filed October 4, 1996. 

FIELD OF THE INVENTION 

[0002] The present invention relates generally to 
process control networks and, more specifically, to a 
method of and an apparatus for performing local device 
and process diagnostics in a process control network 
having distributed control functions. 

DESCRIPTION OF THE RELATED ART 

[0003] Large processes such as chemical, petroleum, 
and other manufacturing and refining processes include 
numerous field devices disposed at various locations to 
measure and control parameters of the process to there- 
by effect control of the process. These field devices may 
be, for example, sensors such as temperature, pres- 
sure, and flow rate sensors as well as control elements 
such as valves and switches. 

[0004] Historically, the process control industry used 
manual operations like manually reading level and pres- 
sure gauges, turning valve wheels, etc., to operate the 
measurement and control field devices within a process. 
Beginning in the 20th century, the process control indus- 
try began using local pneumatic control, in which local 
pneumatic controllers, transmitters, and valve position- 
ers were placed at various locations within a process 
plant to effect control of certain plant locations. With the 
emergence of the microprocessor-based distributed 
control system (DCS) in the 1 970's, distributed electron- 
ic process control became prevalent in the process con- 
trol industry. 

[0005] As is known, a DCS includes an analog or a 
digital computer, such as a programmable logic control- 
ler, connected to numerous electronic monitoring and 
control devices, such as electronic sensors, transmit- 
ters, current-to-pressure transducers, valve positioners, 
etc. located throughout a process. The DCS computer 
stores and implements a centralized and, frequently, 
complex control scheme to effect measurement and 
control of devices within the process to thereby control 
process parameters according to some overall control 
scheme. Usually, however, the control scheme imple- 
mented by a DCS is proprietary to the DCS controller 
manufacturer which, in turn, makes the DCS difficult and 
expensive to expand, upgrade, reprogram, and service 
because the DCS provider must become involved in an 
integral way to perform any of these activities. Further- 
more, the equipment that can be used by or connected 
within any particular DCS may be limited due to the pro- 
prietary nature of DCS controller and the fact that a DCS 
controller provider may not support certain devices or 



functions of devices manufactured by other vendors. 
[0006] To overcome some of the problems inherent in 
the use of proprietary DCSs, the process control indus- 
try has developed a number of standard, open commu- 

5 nication protocols including, for example, the HART®, 
PROFIBUS®, WORLDFIP®, LONWORKS®, De- 
vice-Net®, and CAN protocols, which enable field de- 
vices made by different manufacturers to be used to- 
gether within the same process control network. In fact, 

to any field device that conforms to one of these protocols 
can be used within a process to communicate with and 
to be controlled by a DCS controller or other controller 
that supports the protocol, even if that field device is 
made by a different manufacturerthan the manufacturer 

is of the DCS controller. 

[0007] Moreover, there is now a move within the proc- 
ess control industry to decentralize process control and, 
thereby, simplify DCS controllers or eliminate the need 
for DCS controllers to a large extent. Decentralized con- 

20 . trol is obtained by having process control devices, such 
as valve positioners, transmitters, etc. perform one or 
more process control functions and by then communi- 
cating data across a bus structure for use by other proc- 
ess control devices in performing other control tune- 
rs tions. To implement these control functions, each proc- 
ess control device includes a microprocessor capable 
of performing one or more control functions as well as 
communicating with other process control devices using 
a standard and open communication protocol. In this 

30 manner, field devices made by different manufacturers 
can be interconnected within a process control network 
to communicate with one another and to perform one or 
more process control functions forming a control loop 
without the intervention of a DCS controller. The all-dig- 

35 ital, two-wire bus protocol now being promulgated by the 
Fieldbus Foundation, known as the FOUNDATION™ 
Fieldbus (hereinafter "Fieldbus") protocol is one open 
communication protocol that allows devices made by 
different manufacturers to interoperate and communi- 

40 cate with one another via a standard bus to effect de- 
centralized control within a process. 
[0008] As noted above, the decentralization of proc- 
ess control functions simplifies and, in some cases, 
eliminates the necessity of a proprietary DCS controller 

45 which, in turn, reduces the need of a process operator 
to rely on the manufacturer of the DCS controller to 
change or upgrade a control scheme implemented by 
the DCS controller. However, decentralized control also 
makes it more difficult to perform diagnostics, such as 

50 process diagnostics, which are typically performed by a 
DCS controller. Performing regular diagnostics, such as 
device and process diagnostics, is very important, how- 
ever, when using field devices such as fluid control 
valves in harsh environments in which, for example, 

55 temperature and pressure ranges are widely variable. 
In such environments, substantial maintenance, includ- 
ing periodic preventative maintenance, maintenance 
due to valve breakdown, and testing to verify that valves 
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are functioning properly, is necessary. 
[0009] In a standard DCS environment, a computer 
(such as a personal computer) is coupled to the network 
and performs device diagnostics on, for example, a 
valve or a positioner/valve combination, by sending a s 
diagnostic control signal to the positioner, which then 
forces the valve through a test stroke or test cycle as- 
sociated with the diagnostic control signal. During this 
time, the computer measures outputs of the positioner 
and/or the valve, such as changes in valve position, that 10 
occur in response to the diagnostic control signal and, 
thereafter, performs analysis on the measured outputs 
to determine the operating condition of the valve or the 
positioner/valve device. 

[0010] In one known diagnostic system for fluid con- *5 
trol valves, such as pneumatically actuated valves, a 
pressure sensor is provided to sense varying pressure 
at the input of a valve and a position sensor is provided 
to sense the movement of a valve plug. The valve is op- 
erated through a test operation cycle by supplying a con- 20 
trolled variable pneumatic pressure to the input terminal 
of a pneumatic valve. During, for example, the test op- 
eration cycle of a dynamic scan, the valve plug is moved 
through a desired range, normally from a fully opened 
position to a fully closed position and returned from the 25 
fully closed position to the fully, opened position. Alter- 
natively, step tests may move the valve plug in a series 
of individual steps to test certain valve parameters. 
[0011] During the test operation cycle, the pressure 
sensor provides an output signal that corresponds to 30 
varying pressure at the valve input, and the position sen- 
sor provides an input signal corresponding to the move- 
ment of the valve plug. The respective input or output 
signals of the air pressure at the actuator and the valve 
plug or valve stem position are then processed to derive 35 
data representing the variation in pressure at the valve 
input as a function of movement of the valve plug during 
the test operation cycle. The valve stem load is derived 
by multiplying the air pressure times the effective area 
of the actuator diaphragm. 40 
[001 2] The diagnostic system receives the diagnostic 
commands and communicates the diagnostic informa- 
tion obtained from the sensors via a communication line 
to an external control console or processor/computer. 
The external control console or processor/computer re- 
quests a single diagnostic test and waits for a result 
while the diagnostic system performs the test. When the 
test is complete, the diagnostic system sends the test 
result to the external control console. Many various di- 
agnostic tests are performed for each valve and a con- so 
trol system generally includes many valves so that di- 
agnostic test time can be lengthy. 
[0013] As is also known, in a standard DCS environ- 
ment, a computer such as a DCS controller performs 
process diagnostics using, for example, a valve or a po- 55 
sitioner/valve combination, by sending a diagnostic con- 
trol signal to the positioner, which then forces the valve 
through a test sequence. 



[0014] In a standard DCS environment, device or 
process diagnostics can be performed without rewiring 
or reconfiguring the system to a significant extent be- 
cause the DCS controller or the external computer is al- 
ready configured to control the set points (or other in- 
puts) of the various devices within the process and to 
measure device outputs and other process parameters 
to implement a control strategy associated with the nor- 
mal operation of the process. As a result, performing di- 
agnostics in a standard DCS environment is really a 
matter of using the DCS controller or other external com- 
puter in a slightly different way to control one or more 
devices within the process and using the DCS controller 
or other external computer to measure process or de- 
vice parameters. Thus, in standard DCS environments, 
diagnostic routines can be stored in and used by a cen- 
tralized DCS controller or other centralized external 
computer to perform almost any device or process di- 
agnostic and these diagnostic routines can be used 
without reconfiguring the process control network in any 
significant manner. Unfortunately, because of the cen- 
tralized nature of these diagnostics routines, they do not 
provide much detailed information about field devices. 
[0015] However, in a process control network having 
distributed control functions, a centralized system con- 
troller, to the extent it exists, is not configured to individ- 
ually control all of the field devices within a process and 
is not configured to receive data pertaining to all of the 
appropriate device or process parameters necessary for 
performing device and process diagnostics. Instead, dif- 
ferent process control loops of the control strategy are 
implemented by a number of communicatively linked 
devices located at distributed places within the process 
control network. Typically, these devices are configured 
to use scheduled periodic communications to commu- 
nicate data necessary for implementation of the specific 
control functions associated with a process control loop 
and to communicate other data (such as set point 
changes) using aperiodic or asynchronous communica- 
tions. As a result, in a process control network having 
distributed control functions implemented using sched- 
uled periodic communications, a host device is unable 
to send a strictly deterministic diagnostic control signal 
to a process control device while the system is config- 
ured to implement the normal control strategy because 
the host device must use asynchronous communica- 
tions to deliver the diagnostic control signal and, there- 
fore, has no way of controlling the precise time that the 
diagnostic control signal (or the different portions there- 
of) arrive at the device being tested. In fact, using asyn- 
chronous communications, a host device has no way of 
knowing when the diagnostic control signal (or any par- 
ticular part thereof) actually arrives at the input of the 
device being controlled. As a result, for a host device to 
send a deterministic diagnostic control signal to a device 
in a process control network having distributed control 
functions, the control configuration of the network must 
be reconfigured, which requires taking the process off- 
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line. 

[0016] Furthermore, while some process control de- 
vices, such as the Fieldvue and the Flowscanner devic- 
es manufactured and sold by Fisher Controls Interna- 
tional Inc., are capable of performing self diagnostics, 5 
these devices are limited for use in process control sys- 
tems that use an analog or a combined analog/digital 
communication protocol to effect communications be- 
tween different devices. Currently, there is no process 
control field device capable of performing self diagnos- 
tics in an all-digital system, such as a Fieldbus system, 
or in a communication system that performs distributed 
control functions. 

[0017] Furthermore, process control devices that can 
perform self diagnostics are typically limited to perform- 
ing only the diagnostics hardcoded into the device by 
the device manufacturer and, therefore, are incapable 
of performing diagnostic routines or tests generated by 
a host or a user (which may include routines developed 
by a different device manufacturer). This situation pre- 
vents a user from being able to run the same test on all 
of the different types of devices within a plant. 
[0018] Still further, process control devices that per- 
form self diagnostics are generally incapable of perform- 
ing process diagnostics. Thus, a host device must be 
set up to perform process diagnostics even in a system 
having field devices that can perform some self diag- 
nostics (i.e., device diagnostics). As noted above, how- 
ever, it is difficult for a host device to perform process 
diagnostics in a process control system having distrib- 
uted functions because the control configuration must 
be reconfigured to allow the host to synchronously con- 
trol a device. Moreover, the use of the different control 
scheme during process diagnostics may produce re- 
sults that are erroneous or inaccurate with respect to the 
control scheme run during normal operation of the proc- 
ess. Also, field devices with diagnostic capabilities have 
not been capable of diagnosing other field devices with- 
out local diagnostic capabilities. 

[0019] DE-A-195 10 466 teaches a system having 
control functions distributed throughout different logic 
devices which are connected to a centralised controller 
which, in turn, coordinates activities of the different logic 
devices. 

[0020] D2 "Advanced systems simplify control", Ma- 
chine design, vol. 68, no. 12, 11 July 1996, pages 118, 
120 and WO-A-96/1 2993 teaches the use of Fieldbus 
protocols and Fieldbus devices. 

SUMMARY OF THE INVENTION 

[0021] The present invention is directed to a method 
of and a device for performing device and process diag- 
nostics on and from a particular process control device 
within a process control network and, preferably, within 
a process control network having distributed control 
functions. According to the present invention, a diagnos- 
tic test routine (which may be a device or a process di- 



agnostic test routine) is stored in and implemented by a . 
process control device to perform, diagnostics on that 
process control device without the necessity of recon- 
figuring the control scheme associated with the process 
control network. As a result, the diagnostic test routine 
may be implemented according to the present invention 
while a process is being controlled under essentially the 
same control strategy as that implemented during nor- 
mal operation of the process. Moreover, the device or 
process diagnostic test routine implemented by a proc- 
ess control device according to the present invention, 
may be generated by a user at a host device and deliv- 
ered to the process control device before the diagnostic 
test routine is run, which enables the process control 
device to implement any desired diagnostic test routine, 
including routines supplied by other device manufactur- 
ers. 

[0022] According to one aspect of the present inven- 
tion, a field device, capable of being used in a process 
control system that has a plurality of field devices mu- 
tually coupled by a two- wire, digital, powered bus, in- 
cludes a pneumatically operated fluid control valve, a 
positioner coupled by a pneumatic pressure line to the 
fluid control valve for generating a pneumatic pressure 
that causes the fluid control valve to move to a position 
ranging from an open position to a closed position and 
a position sensor coupled to the positioner and to the 
fluid control valve for sensing the position of the fluid 
control valve. A pressure sensor is coupled to the pneu- 
matic pressure line for sensing the pneumatic pressure 
applied to the fluid control valve and an electrical to 
pneumatic transducer is coupled to the positioner by the 
pneumatic pressure line for controlling the pneumatic 
pressure in the pneumatic pressure line as a function of 
an electrical signal. An electronic controller is coupled 
to the electrical to pneumatic transducer, the pressure 
sensor, and the position sensor, and includes control 
logic that determines the electrical signal based on feed- 
back signals indicative of a pressure sensed by the pres- 
sure sepsor and a position sensed by the position sen- 
sor and based on the field device control signal. More- 
over, a digital interface is coupled to the two-wire, digital, 
powered bus and to the electronic controller and in- 
cludes a circuit for supplying power derived from the 
powered bus to the field device and a two-way commu- 
nication circuit that receives signals including the field 
device control signal from the bus and that transmits sig- 
nals indicative of a status of the field device to the bus. 
[0023] According to another aspect of the present in- 
vention, a field device for use in a process control net- 
work having a plurality of devices communicatively cou- 
pled by a two-wire, all-digital communication bus in- 
cludes a connector that connects to the two-wire, all- 
digital bus to enable all-digital communication over the 
bus, a memory that stores a diagnostic test routine hav- 
ing a series of diagnostic test instructions, and a con- 
troller that performs the diagnostic test instructions 
stored in the memory to implement a diagnostic test us- 
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ing the field device. The field device also includes a data 
collection unit that collects diagnostic data generated 
during the diagnostic test and a communication unit that 
communicates the collected diagnostic . data over the 
bus in an all-digital format. 

[0024] Preferably, the controller includes a program 
language interpreter adapted to interpret a program lan- 
guage and the diagnostic test instructions are stored in 
the program language.and are delivered to the controller 
of the field device from a second one of the plurality of 
devices via the bus. Likewise, the diagnostic test in- 
structions may perform a device and/or a process diag- 
nostic, as desired. If the diagnostic test instructions 
specify a process diagnostic, the data collection unit is 
adapted to receive data generated by other devices dur- 
ing the diagnostic test. 

[0025] According to a still f u rther aspect of the present 
invention, a field device for use in a process control net- 
work having a plurality of devices communicatively cou- 
pled by a bus includes a memory that stores a diagnostic 
test routine having a series of diagnostic test instruc- 
tions, a device controller that performs the diagnostic 
test instructions stored in the memory to implement a 
diagnostic test, a data collection unit that collects, diag- 
nostic data generated during the diagnostic test and a 
communication unit that receives the diagnostic test in- 
structions from a second one of the plurality of devices 
via the bus, that stores the received diagnostic test in- 
structions in the memory and that communicates the 
collected diagnostic data over the bus. 
[0026] According to a yet another aispect of the 
present invention, a field device for use in performing a 
process diagnostic test in a process control network 
having a plurality of devices communicatively coupled 
by a bus includes a memory that stores a process diag- 
nostic test routine having a series of diagnostic test in- 
structions to be implemented by the field device and a 
device controller that performs the process diagnostic 
test instructions stored in the memory to implement a 
process diagnostic test. The field device also includes 
a data collection unit that collects diagnostic data gen- 
erated by the field device during the process diagnostic 
test and that receives further process diagnostic data 
from a second one of the plurality of devices via the bus. 
A communication unit within the field device communi- 
cates the collected diagnostic data and the further proc- 
ess diagnostic data over the bus after the process diag- 
nostic test is completed. 

[0027] The present invention is defined by Claims 1 
to 40 and relate to a field device for use in a process 
control network having a plurality of devices communi- 
catively coupled by an all-digital communication bus: 
The field device includes a connector that connects to 
the all-digital bus to enable all-digital communication 
over the bus. A memory stores a diagnostic test routine 
having a series of diagnostic test instructions. A control- 
ler performs the diagnostic test instructions stored in the 
memory to implement a diagnositc test using the field 



device. A data collection unit collects diagnostic data 
generated during the diagnostic test, A communication 
unit communicates the collected diagnostic data over 
the bus in an all-digital format. 

5 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0028] 

10 Fig. 1 is a schematic block diagram of a process 
control network using the Fieldbus protocol; 
Fig. 2 is a schematic block diagram of a Fieldbus 
device having a set of three function blocks therein; 
Fig. 3 is a schematic block diagram illustrating the 

is function blocks within some of the devices of the 
process control network of Fig. 1 ; 
Fig. 4 is a control loop schematic for a typical proc- 
ess control loop within the process control network 
of Fig. 1 ; 

20 Fig. 5 is a timing schematic for a macrocycle of a 
segment of the bus of the process control network 
of Fig. 1 ; ... 
Fig. 6 is a schematic block diagram showing a dig- 
ital field device having a two-wire, loop-powered, 

25 two-way digitally-communicating positioner; 

Fig. 7 is a block diagram illustrating a suitable field 
device controller for use in controlling the digital 
field device of Fig. 6; 

Fig. 8 is a flow chart illustrating a technique for per- 

30 forming diagnostic tests; 

Fig. 9 is a flow chart illustrating a diagnostic test pro- 
tocol for testing the digital field device of Fig. 6; 
Figs. 10A, 10B, and 10C are graphs depicting dif- 
ferent diagnostic test signals used to perform de- 

35 vice diagnostics according to the present invention; 
Figs. 11 A and 11 B are control loop schematics in- 
cluding a diagnostic data collection function block 
according to the present invention; and 
Fig. 12 is a flow chart illustrating a diagnostic test 

^o protocol for performing a process diagnostic test us- 
ing the diagnostic data collection function block of 
Fig. 11. 

DESCRIPTION OF THE PREFERRED 
45 EMBODIMENTS 

[0029] While the device and process diagnostics of 
the present invention are described in detail in conjunc- 
tion with a process control network that implements 

so process control functions in a decentralized or distribut- 
ed manner using a set of Fieldbus devices, it should be 
noted that the diagnostics of the present invention can 
be used with process control networks that perform dis- 
tributed control functions using other types of field de- 

55 vices and communication protocols, including protocols 
that rely on other than two-wire buses and protocols that 
support only analog or both analog and digital commu- 
nications. Thus, for example, the device or process di- 
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agnostics of the present invention can be used in any 
process control network that performs distributed con- 
trol functions even if this process control network uses 
the HART, PROFIBUS, etc. communication protocols or 
any other communication protocols that now exist or that 
may be developed in the future. Furthermore, the diag- 
nostics of the present invention may also be used with 
standard process control networks that do not perform 
distributed control functions, such as HART networks, 
etc., and may be used within any desired process con- 
trol device, including valves, positioners, transmitters, 
etc. 

[0030] Before discussing the details of the diagnostics 
of the present invention, a general description of the 
Fieldbus protocol, field devices configured according to 
this protocol, and the way in which communication oc- 
curs in a process control network that uses the Fieldbus 
protocol will be provided. However, it should be under- 
stood that, while the Fieldbus protocol is a relatively new 
all-digital communication protocol developed for use in 
process control networks, this protocol is known in the 
art and is described in detail in numerous articles, bro- 
chures and specifications published, distributed, and 
available from, among others, the Fieldbus Foundation, 
a not-for-profit organization headquartered in Austin, 
Texas. In particular, the Fieldbus protocol, and the man- 
ner of communicating with and storing data in devices 
using the Fieldbus protocol, is described in detail in the 
manuals entitled Communications Technical Specifica- 
tion and User Layer Technical Specification from the 
Fieldbus Foundation, which are hereby expressly incor- 
porated by reference herein in their entirety. 
[0031] The Fieldbus protocol is an all-digital, serial, 
two-way communication protocol that provides a stand- 
ardized physical interface to a two-wire loop or bus in- 
terconnecting "field" equipment such as sensors, actu- 
ators, controllers, valves, etc. located in an instrumen- 
tation or process control environment of, for example, a 
factory or a plant. The Fieldbus protocol provides, in ef- 
fect, a local area network for field instruments (field de- 
vices) within a process facility, which enables these field 
devices to perform control functions at locations distrib- 
uted throughout a process and to communicate with one 
another before and after the performance of these con- 
trol functions to implement an overall control strategy. 
Because the Fieldbus protocol enables control functions 
to be distributed throughout a process control network, 
it reduces the complexity of, or entirely eliminates the 
necessity of the centralized process controller typically 
associated with a DCS. 

[0032] Referring to Fig. 1 , a process control network 
10 using the Fieldbus protocol may include a host 12 
connected to a number of other devices such as a pro- 
gram logic controller (PLC) 13, a number of controllers 
14, another host device 15 and a set of field devices 16, 
1 8, 20, 22, 24, 26, 28, 30, and 32 via a two-wire Fieldbus 
loop or bus 34. The bus 34 includes different sections 
or segments, 34a, 34b, and 34c which are separated by 



bridge devices 30 and 32. Each of the sections 34a, 34b, 
and 34c interconnects a subset of the devices attached 
to the bus 34 to enable communications between the 
devices in a manner described hereinafter. Of course, 

5 the network of Fig. 1 is illustrative only, there being many 
other ways in which a process control network may be 
configured using the Fieldbus protocol. Typically, a con- 
figurer is located in one of the devices, such as the host 
1 2, and is responsible for setting up or configuring each 

10 of the devices (which are "smart" devices in that they 
each include a microprocessor capable of performing 
communication and, in some cases, control functions) 
as well as recognizing when new field devices are con- 
nected to the bus 34, when field devices are removed 

15 from the bus 34, receiving some of the data generated 
by the field devices 16-32, and interfacing with one or 
more user terminals, which may be located in the host 
12 or in any other device connected to the host 12 in 
any manner. 

20 [0033] The bus 34 supports or allows two-way, purely 
digital communication and may also provide a power 
signal to any or all of the devices connected thereto, 
such as the field devices 16-32. Alternatively, any or all 
of the devices 1 2-32 may have their own power supplies 

25 or may be connected to external power supplies via sep- 
arate wires (not shown). While the devices 12-32 are 
illustrated in Fig. 1 as being connected to the bus 34 in 
a standard bus-type connection, in which multiple de- 
vices are connected to the same pair of wires making 

30 up the bus segments 34a, 34b, and 34c, the Fieldbus 
protocol allows other device/wire topologies including 
point-to-point connections, in which each device is con- 
nected to a controller or a host via a separate two-wire 
pair (similar to typical 4-20 mA analog DCS systems), 

35 and tree or "spur" connections in which each device is 
connected to a common point in a two-wire bus which 
may be, for example, a junction box or a termination ar- 
ea in one of the field devices within a process control 
network; 

40 [0034] Data may be sent over the different bus seg- 
ments 34a, 34b, and 34c at the same or different com- 
munication baud rates or speeds according to the Field- 
bus protocol. For example, the Fieldbus protocol pro- 
vides a 31 .25 Kbit/s communication rate (H1 ), illustrated 

45 as being used by the bus segments 34b and 34c of Fig. 
1, and a 1.0 Mbit/s and/or a 2.5 Mbit/s (H2) communi- 
cation rate, which will be typically used for advanced 
process control, remote input/output, and high speed 
factory automation applications and is illustrated as be- 

50 ing used by the bus segment 34a of Fig. 1 . Likewise, 
data may be sent over the bus segments 34a, 34b, and 
34c according to the Fieldbus protocol using voltage 
mode signaling or current mode signaling. Of course, 
the maximum length of each segment of the bus 34 is 

55 not strictly limited but is, instead, determined by the 
communication rate, cable type, wire size, bus power 
option, etc. of that section. 

[0035] The Fieldbus protocol classifies the devices 
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that can be connected to the bus 34 into three catego- 
ries, namely, basic devices, link master devices, and 
bridge devices. Basic devices (such as devices 18, 20, 
24, and 28 of Fig. 1 ) can communicate, that is, send and 
receive communication signals on or from the bus 34, 
but are not capable of controlling the order or timing of 
communication that occurs on the bus 34. Link master 
devices (such as devices 16, 22, and 26 as well as the 
host 1 2 of Fig. 1 ) are devices that communicate over the 
bus 34 and are capable of controlling the flow of and the 
timing of communication signals on the bus 34. Bridge 
devices (such as devices 30 and 32 of Fig. 1 ) are devic- 
es configured to communicate on and to interconnect 
individual segments or branches of a Fieldbus bus to 
create larger process control networks. If desired, 
bridge devices may convert between different data 
speeds and/or different data signaling formats used on 
the different segments of the bus 34, may amplify sig- 
nals traveling between the segments of the bus 34, may 
filter the signals flowing between the different segments 
of the bus 34 and pass only those signals destined to 
be received by a device on one of the bus segments to 
which the bridge is coupled and/or may take other ac- 
tions necessary to link different segments of the bus 34. 
Brjdge devices that connect bus segments that operate 
at different speeds must have link master capabilities at 
the lower speed segment side of the bridge. The hosts 
12 and 15, the PLC 13, and the controllers 14 may be 
any type of fieldbus device but, typically, will be link mas- 
ter devices. 

[0036] Each of the devices 12-32 is capable of com- 
municating over the bus 34 and, importantly, is capable 
of independently performing one or more process con- 
trol functions using data acquired by the device, from 
the process, or from a different device via communica- 
tion signals on the bus 34. Fieldbus devices are, there- 
fore, capable of directly implementing portions of an 
overall control strategy which, in the past, were per- 
formed by a centralized digital controller of a DCS. To 
perform control functions, each Fieldbus device in- 
cludes one or more standardized "blocks" which are im- 
plemented in a microprocessor within the device. In par- 
ticular, each Fieldbus device includes one resource 
block and may include zero or more function blocks, and 
zero or more transducer blocks. These blocks are re- 
ferred to as block objects. 

[0037] A resource block stores and communicates 
device specific data pertaining to some of the charac- 
teristics of a Fieldbus device including, for example, a 
device type, a device revision indication, and indications 
of where other device specific information may be ob- 
tained within a memory of the device. While different de- 
vice manufacturers may store different types of data in 
the resource block of a field device, each field device 
conforming to the Fieldbus protocol includes a resource 
block that stores some data. 

[0038] A function block defines and implements an in- 
put function, an output function, or a control function as- 



sociated with the field device and, thus, function blocks, 
are generally referred to as input, output, and control 
function blocks. However, other categories of function 
blocks such as hybrid function blocks may exist or may 

5 be developed in the future. Each input or output function 
block produces at least one process control input (such 
as a process variable from a process measurement de- 
vice) or process control output (such as a valve position 
sent to an actuation device) while each control function 

10 block uses an algorithm (which may be proprietary in 
nature) to produce one or more process outputs from 
one or more process inputs and control inputs. Exam- 
ples of standard function blocks include analog input 
(Al), analog output (AO), bias (B), control selector (CS), 

is discrete input (Dl), discrete output (DO), manual loader 
(ML), proportional/derivative (PD), proportional/inte- 
gral/derivative (PID), ratio (RA), and signal selector (SS) 
function blocks. However, other types of function blocks 
exist and new types of function blocks may be defined 

20 or created to operate in the Fieldbus environment. 
[0039] A transducer block couples the inputs and out- 
puts of a function block to local hardware devices, such 
as sensors and device actuators, to enable function 
blocks to read the outputs of local sensors and to com- 

25 mand local devices to perform one or more functions 
such as moving a valve member. Transducer blocks typ- 
ically contain information that is necessary to interpret 
signals delivered by a local device and to properly con- 
trol local hardware devices including, for example, infor- 

.30 mation identifying the type of a local device, calibration 
information associated with a local device, etc. A single 
transducer block is typically associated with each input 
or output function block. 

[0040] Most function blocks are capable of generating 

35 alarm or event indications based on predetermined cri- 
teria and are capable of operating differently in different 
modes. Generally speaking, function blocks may oper- 
ate in an automatic mode, in which, for example, the al- 
gorithm of a function block operates automatically; an 

40 operator mode in which the input or output of, for exam- 
ple, a function block, is controlled manually; an out-of- 
service mode in which the block does not operate; a cas- 
cade mode in which the operation of the block is affected 
from (determined by) the output of a different block; and 

45 one or more remote modes in which a remote computer 
determines the mode of the block. However, other 
modes of operation exist in the Fieldbus protocol. 
[0041] Importantly, each block is capable of commu- 
nicating with other blocks in the same or different field 

50 devices over the Fieldbus bus 34 using standard mes- 
sage formats defined by the Fieldbus protocol. As a re- 
sult, combinations of function blocks (in the same or dif- 
ferent devices) may communicate with each other to 
produce one or more decentralized control loops. Thus, 

55 for example, a PID function block in one field device may 
be connected via the bus 34 to receive an output of an 
Al function block in a second field device, to deliver data 
to an AO function block in third field device, and to re- 
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ceive an output of the AO function block as feedback to 
create a process control loop separate and apart from 
any DCS controller. In this manner, combinations of 
function blocks move control functions out of a central- 
ized DCS environment, which allows DCS multifunction 5 
controllers to perform supervisory or coordinating func- 
tions or to be eliminated altogether. Furthermore, func- 
tion blocks provide a graphical, block-oriented structure 
for easy configuration of a process and enable the dis- 
tribution of functions among field devices from different 10 
suppliers because these blocks use a consistent com- 
munication protocol. 

[0042] In addition to containing and implementing 
block objects, each field device includes one or more 
other objects including link objects, trend objects, alert 15 
objects, and view objects. Link objects define the links 
between the inputs and outputs of blocks (such as func- 
tion blocks) both internal to the field device and across 
the Fieldbus bus 34. 

[0043] Trend objects allow local trending of function 20 
block parameters for access by other devices such as 
the host 1 2 or controllers 1 4 of Fig. 1 . Trend objects re- 
tain short-term historical data pertaining to some, for ex- 
ample, function block parameter and report this data to 
other devices or function blocks via the bus 34 in an 25 
asynchronous manner. Alert objects report alarms and 
events over the bus 34. These alarms or events may 
relate to any event that occurs within a device or one of 
the blocks of a device. View objects are predefined 
groupings of block parameters used in standard human/ 30 
machine interfacing and may be sent to other devices 
for viewing from time to time. 

[0044] Referring now to Fig. 2, a Fieldbus device, 
which may be, for example, any of the field devices 
1 6-28 of Fig. 1 , is illustrated as including three resource 35 
blocks 48, three function blocks 50, 51, and 52 and two 
transducer blocks 53 and 54. One of the function blocks 
50 (which may be an input function block) is coupled 
through the transducer block 53 to a sensor 55, which 
may be, for example, a temperature sensor, a set point 
indication sensor, etc. The second function block 51 
(which may be an output function block) is coupled 
through the transducer block 54 to an output device 
such as a valve 56. The third function block 52 (which 
may be a control function block) has a trend object 57 
associated therewith for trending the input parameter of 
the function block 52. 

[0045] Link objects 58 define the block parameters of 
each of the associated blocks and alert objects 59 pro- 
vide alarms or event notifications for the each of the as- 
sociated blocks. View objects 60 are associated with 
each of the function blocks 50, 51, and 52 and include 
or group data lists for the function blocks with which they 
are associated. These lists contain information neces- 
sary for each of a set of different defined views. Of 
course, Fig. 2 is merely exemplary and other numbers 
of and types of block objects, link objects, alert objects, 
trend objects, and view objects may be provided in any 



field device. 

[0046] Referring now to Fig. 3, a block diagram of the 
process control network 1 0 depicting the devices 1 6, 1 8, 
and 24 as positioner/valve devices and the devices 20, 
22, 26, and 28 as transmitters also illustrates the func- 
tion blocks associated with the positioner/valve 16, the 
transmitter 20, and the bridge 30. As illustrated in Fig. 
3, the positioner/valve 16 includes a resource (RSC) 
block 61, a transducer (XDR) block 62, and a number 
of function blocks including an analog output (AO) func- 
tion block 63, two PID function blocks 64 and 65, and a 
signal select (SS) function block 69. The transmitter 20 
includes a resource block 61 , two transducer blocks 62, 
and two analog input (Al) function blocks 66 and 67. Al- 
so, the bridge 30 includes a resource block 61 and a 
PID function block 68. 

[0047] As will be understood, the different function 
blocks of Fig. 3 may operate together (by communicat- 
ing over the bus 34) in a number of control loops and 
the control loops in which the function blocks of the po- 
sitioner/valve 16, the transmitter 20, and the bridge 30 
are located are identified in Fig. 3 by a loop identification 
block connected to each of these function blocks. Thus, 
as illustrated in Fig. 3, the AO function block 63 and the 
PID function block 64 of the positioner/valve 16 and the 
Al function block 66 of the transmitter 20 are connected 
within a control loop indicated as LOOP1 , while the SS 
function block 69 of the positioner/valve 1 6, the Al func- 
tion block 67 of the transmitter 20, and the PID function 
block 68 of the bridge 30 are connected in a control loop 
indicated as LOOP2. The other PID function block 65 of 
the positioner/valve 1 6 is connected within a control loop 
indicated as LOOP3. 

[0048] The interconnected function blocks making up 
the control loop indicated as LOOP1 in Fig. 3 are illus- 
trated in more detail in the schematic of this control loop 
depicted in Fig. 4. As can be seen from Fig. 4, the control 
loop LOOP1 is completely formed by communication 
links between the AO function block 63 and the PID 
function block 64 of the positioner/valve 16 and the Al 
function block 66 of the transmitter 20 (Fig. 3). The con- 
trol loop diagram of Fig. 4 illustrates the communication 
interconnections between these function blocks using 
lines attaching the process and control inputs and out- 
puts of these functions blocks. Thus, the output of the 
Al function block 66, which may comprise a process 
measurement or process parameter signal, is commu- 
nicatively coupled via the bus segment 34b to the input 
of the PID function block 64 which has an output com- 
prising a control signal communicatively coupled to an 
input of the AO function block 63. An output of the AO 
function block 63, which comprises a feedback signal 
indicating, for example, the position of the valve 16, is 
connected to a control input of the PID function block 
64. The PID function block 64 uses this feedback signal 
along with the process measurement signal from the Al 
function block 66 to implement proper control of the AO 
function block 63. Of course the connections indicated 
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by the lines in the control loop diagram of Fig. 4 may be 
performed internally within a field device when, as with 
the case of the AO and the PID function blocks 63 and 
64, the function blocks are within the same field device 
(e.g., the positioner/valve 1 6), or these connections may 
be implemented over the two-wire communication bus 
34 using standard Fieldbus synchronous communica- 
tions. Of course, other control loops are implemented 
by other function blocks that are communicatively inter- 
connected in other configurations. 
[0049] To implement and perform communication and 
control activities, the Fieldbus protocol uses three gen- 
eral categories of technology identified as a physical lay- 
er, a communication "stack," and a user layer. The user 
layer includes the control and configuration functions 
provided in the form of blocks (such as function blocks) 
and objects within any particular process control device 
or field device. The user layer is typically designed in a 
proprietary manner by the device manufacturer but must 
be capable of receiving and sending messages accord- 
ing to the standard message format defined by the Field- 
bus protocol and of being configured by a user in stand- 
ard manners. The physical layer and the communication 
stack are necessary to effect communication between 
different blocks of different field devices in a standard- 
ized manner using the two-wire bus 34 and may be mod- 
eled by the well-known Open Systems Interconnect 
(OSI) layered communication model. 
[0050] The physical layer, which corresponds to OSI 
layer 1 , is embedded in each field device and the bus 
34 and operates to convert electromagnetic signals re- 
ceived from the Fieldbus transmission medium (the two- 
wire bus 34) into messages capable of being used by 
the communication stack of the field device. The phys- 
ical layer may be thought of as the bus 34 and the elec- 
tromagnetic signals present on the bus 34 at the inputs 
and outputs of the field devices. 
[0051] The communication stack, which is present in 
each Fieldbus device, includes a data link layer, which 
corresponds to OSI layer 2, a Fieldbus access sublayer, 
and a Fieldbus message specification layer, which cor- 
responds to OSI layer 6. There is no corresponding 
structure for OSI layers 3-5 in the Fieldbus protocol. 
However, the applications of a fieldbus device comprise 
a layer 7 while a user layer is a layer 8, not defined in 
the OSI protocol. Each layer in the communication stack 
is responsible for encoding or decoding a portion of the 
message or signal that is transmitted on the Fieldbus 
bus 34. As a result, each layer of the communication 
stack adds or removes certain portions of the Fieldbus 
signal such as preambles, start delimiters, and end de- 
limiters and, in some cases, decodes the stripped por- 
tions of the Fieldbus signal to identify where the rest of 
the signal or message should be sent or if the signal 
should be discarded because, for example, it contains 
a message or data for function blocks that are not within 
the receiving field device. 

[0052] The data link layer controls transmission of 



messages onto the bus 34 and manages access to the 
bus 34 according to a deterministic centralized bus 
scheduler called a link active scheduler, to be described 
in more detail below. The data link layer removes a pre- 

5 amble from the signals on the transmission medium and 
may use the received preamble to synchronize the in- 
ternal clock of the field device with the incoming Field- 
bus signal. Likewise, the data link layer converts mes- 
sages on the communication stack into physical Field- 

10 bus signals and encodes these signals with clock infor- 
mation to produce a "synchronous serial" signal having 
a proper preamble for transmission on the two-wire bus 
34. During the decoding process, the data link layer rec- 
ognizes special codes within the preamble, such as start 

15 delimiters and end delimiters, to identify the beginning 
and the end of a particular Fieldbus message and may 
perform a checksum to verify the integrity of the signal 
or message received from the bus 34. Likewise, the data 
link layer transmits Fieldbus signals on the bus 34 by 

20. adding start and end delimiters to messages on the 
communication stack and placing these signals on the 
transmission medium at the appropriate time. 
[0053] The Fieldbus message specification layer al- 
lows the user layer (i.e., the function blocks, objects, etc. 

25 of a field device) to communicate across the bus 34 us- 
ing a standard set of message formats and describes 
the communication services, message formats, and 
protocol behaviors required to build messages to be 
placed onto the communication stack and to be provided 

30 to the user layer. Because the Fieldbus message spec- 
ification layer supplies standardized communications 
for the user layer, specific Fieldbus message specifica- 
tion communication services are defined for each type 
of object described above. For example, the Fieldbus 

35 message specification layer includes object dictionary 
services which allows a user to read an object dictionary 
of a device. The object dictionary stores object descrip- 
tions that describe or identify each of the objects (such 
as block objects) of a device. The Fieldbus message 

<o specification layer also provides context management 
services which allows a user to read and change com- 
munication relationships, known as virtual communica- 
tion relationships (VCRs) described hereinafter, associ- 
ated with one or more objects of a device. Still further, 

45 the Fieldbus message specification layer provides var- 
iable access services, event services, upload and down- 
load services, and program invocation services, all of 
which are well known in the Fieldbus protocol and, 
therefore, will not be described in more detail herein. 

50 The Fieldbus access sublayer maps the Fieldbus mes- 
sage specification layer into the data link layer. 
[0054] To allow or enable operation of these layers, 
each Fieldbus device includes a management informa- 
tion base (MIB), which is a database that stores VCRs, 

55 dynamic variables, statistics, link active scheduler tim- 
ing schedules, function block execution timing sched- 
ules and device tag and address information. Of course, 
the information within the MIB may be accessed or 
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changed at any time using standard Fieldbus messages 
or commands. Furthermore, a device description is usu- 
ally provided with each device to give a user or a host 
an extended view of the information in the VFD. A device 
description, which must typically be tokenized to be ,5 
used by a host, stores information needed for the host 
to understand the meaning of the data in the VFDs of a 
device. 

[0055] As will be understood, to implement any con- 
trol strategy using function blocks distributed throughout w 
a process control network, the execution of the function 
blocks must be precisely scheduled with respect to the 
execution of other function blocks in a particular control 
loop. Likewise, communication between different func- 
tion blocks must be precisely scheduled on the bus 34 15 
so that the proper data is provided to each function block 
before that block executes. 

[0056] The way in which different field devices (and 
different blocks within field devices) communicate over 
the Fieldbus transmission medium will now be de- 20 
scribed with respect to Fig. 1 . For communication to oc- 
cur, one of the link master devices on each segment of 
the bus 34 (for example, devices 12, 16, and 26) oper- 
ates as a link active scheduler (LAS) that actively sched- 
ules and controls communication on the associated seg- 25 
ment of the bus 34. The LAS for each segment of the 
bus 34 stores and updates a communication schedule 
(a link active schedule) containing the times that each 
function block of each device is scheduled to start peri- 
odic communication activity on the bus 34 and the length 30 
of time for which this communication activity is to occur. 
While there may be one and only one active LAS device 
on each segment of the bus 34, other link master devic- 
es (such as the device 22 on the segment 34b) may 
serve as backup LASs and become active when, for ex- 35 
ample, the current LAS fails. Basic devices do not have 
the capability to become an LAS at any time. 
[0057] Generally speaking, communication activities 
over the bus 34 are divided into repeating macrocycles, 
each of which includes one synchronous communica- *o 
tion for each function block active on any particular seg- 
ment of the bus 34 and one or more asynchronous com- 
munications for one or more of the functions blocks or 
devices active on a segment of the bus 34. A device 
may be active, i.e., send data to and receive data from 45 
any segment of the bus 34, even if it is physically con- 
nected to a different segment of the bus 34, through co- 
ordinated operation of the bridges and the LASs on the 
bus 34. 

[0058] During each macrocycle, each of the function 50 
blocks active on a particular segment of the bus 34 ex- 
ecutes, usually at a different, but precisely scheduled 
(synchronous) time and, at another precisely scheduled 
time, publishes its output data on that segment of the 
bus 34 in response to a compel data command gener- 55 
ated by the appropriate LAS. Preferably, each function 
block is scheduled to publish its output data shortly after 
the end of the execution period of the function block. 
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Furthermore, the data publishing times of the different 
function blocks are scheduled serially so that no two 
function blocks on a particular segment of the bus 34 
publish data at the same time. During the time that syn- 
chronous communication is not occurring, each field de- 
vice is allowed, in turn, to transmit alarm data, view data, 
etc. in an asynchronous manner using token driven 
communications. The execution times and the amount 
of time necessary to complete execution of each func- 
tion block are stored in the management information 
base (MIB) of the device in which the function block re- 
sides while, as noted above, the times for sending the 
compel data commands to each of the devices on a seg- 
ment of the bus 34 are stored in the MIB of the LAS de- 
vice for that segment. These times are typically stored 
as offset times because they identify the times at which 
a function block is to execute or send data as an offset 
from the beginning of an "absolute link schedule start 
time, ■ which is known by all of the devices connected 
to the bus 34. 

[0059] To effect communications during each macro- 
cycle, the LAS, for example, the LAS 16 of the bus seg- 
ment 34b, sends a compel data command to each of the 
devices on the bus segment 34b according to the list of 
transmit times stored in the link active schedule. Upon 
receiving a compel data command, a function block of 
a device publishes its output data on the bus 34 for a 
specific amount of time. Because each of the functions 
blocks is typically scheduled to execute so that execu- 
tion of that block is completed shortly before the block 
is scheduled to receive a compel data command, the 
data published in response to a compel data command 
should be the most recent output data of the function 
block. However, if a function block is executing slowly 
and has not latched new outputs when it receives the 
compel data command, the function block publishes the 
output data generated during the last run of the function 
block and indicates that the published data is old data 
using a time-stamp. 

[0060] After the LAS has sent a compel data com- 
mand to each of the function blocks on particular seg- 
ment of the bus 34 and during the times that function 
blocks are executing, the LAS may cause asynchronous 
communication activities to occur. To effect asynchro- 
nous communication, the LAS sends a pass token mes- 
sage to a particular field device. When a field device re- 
ceives a pass token message, that field device has full 
access to the bus 34 (or a segment thereof) and can 
send asynchronous messages, such as alarm messag- 
es, trend data, operator set point changes, etc. until the 
messages are complete or until a maximum allotted "to- 
ken hold time" has expired. Thereafter the field device 
releases the bus 34 (or any particular segment thereof) 
and the LAS sends a pass token message to another 
device. This process repeats until the end of the mac- 
rocycle or until the LAS is scheduled to send a compel 
data command to effect synchronous communication. 
Of course, depending on the amount of message traffic 



10 



19 



EP 0 929 850 B1 



20 



and the number of devices and blocks coupled to any 
particular segment of the bus 34, not every device may 
receive a pass token message during each macrocycle. 
[0061] Fig. 5 illustrates a timing schematic depicting 
the times at which function blocks on the bus segment s 
34b of Fig. 1 execute during each macrocycle of the bus 
segment 34b and the times at which synchronous com- 
munications occur during each macrocycle associated 
with the bus segment 34b. In the timing schedule of Fig. 
5, time is indicated on the horizontal axis and activities 
associated with the different function blocks of the po- 
sitioner/valve 16 and the transmitter 20 (of Fig. 3) are 
illustrated on the vertical axis. The control loop in which 
each of the functions blocks operates is identified in Fig. 
5 as a subscript designation. Thus AI LO0P1 refers to the 
Al function block 66 of the transmitter 20, PID LOOP1 re- 
fers to the PID function block 64 of the positioner/valve 
16, etc. The block execution period of each of the illus- 
trated function blocks is depicted by a cross-hatched 
box while each scheduled synchronous communication 
is identified by a vertical bar in Fig. 5. 
[0062] Thus, according to the timing schedule of Fig. 
5, during any particular macrocycle of the segment 34b 
(Fig. 1 ), the AI LOOP1 function block executes first for the 
time period specified by the box 70. Then, during the 
time period indicated by the vertical bar 72, the output 
of the AI LO opi function block is published on the bus 
segment 34b in response to a compel data command 
from the LAS for the bus segment 34b. Likewise, the 
boxes 74, 76, 78, 80, and 81 indicate the execution 
times of the function blocks PID LOOP1l AI LOO p 2 , 
ao loopv ss loop2. and pid loop3> respectively (which 
are different for each of the different blocks), while the 
vertical bars 82, 84, 86, 88, and 89 indicate the times 
that the function blocks PID LOOP1 , AI LOO P2> AO LOOP1 , 
SS LOOP2 , and PID LOOP3 , respectively, publish data on 
the bus segment 34b. 

[0063] As will be apparent, the timing schematic of 
Fig. 5 also illustrates the times available for asynchro- 
nous communication activities, which may occur during 
the execution times of any of the function blocks and 
during the time at the end of the macrocycle during 
which no function blocks are executing and when no 
synchronous communication is taking place on the bus 
segment 34b. Of course, if desired, different function 
blocks can be intentionally scheduled to execute at the 
same time and not all function blocks must publish data 
on the bus if, for example, no other device subscribes 
to the data produced by a function block. 
[0064] Field devices are able to publish or transmit da- 
ta and messages over the bus 34 using one of three 
virtual communication relationships (VCRs) defined in 
the Fieldbus access sublayer of the stack of each field 
device. A client/server VCR is used for queued, un- 
scheduled, user initiated, one to one, communications 
between devices on the bus 34. Such queued messag- 
es are sent and received in the order submitted for trans- 
mission, according to their priority, without overwriting 



previous messages. Thus, a field device may use a cli- 
ent/server VCR when it receives a pass token message 
from an LAS to send a request message to another de- 
vice on the bus 34. The requester is called the "client" 
and the device that receives the request is called the 
"server." The server sends a response when it receives 
a pass token message from the LAS. The client/server 
VCR is used, for example, to effect operator initiated re- 
quests such as set point changes, tuning parameter ac- 
cess and changes, alarm acknowledgements, and de- 
vice uploads and downloads. 

[0065] A report distribution VCR is used for queued, 
unscheduled, user initiated, one to many communica- 
tions. For example, when a field device with an event or 
a trend report receives a pass token from an LAS, that 
field device sends its message to a "group address" de- 
fined in the Fieldbus access sublayer of the communi- 
cation stack of that device. Devices that are configured 
to listen on that VCR will receive the report. The report 
distribution VCR type is typically used by Fieldbus de- 
vices to send alarm notifications to operator consoles. 
[0066] A publisher/subscriber VCR type is used for 
buffered, one to many communications. Buffered com- 
munications are ones that store and send only the latest 
version of the data and, thus, new data completely over- 
writes previous data. Function block outputs, for exam- 
ple, comprise buffered data: A "publisher" field device 
publishes or broadcasts a message using the publisher/ 
subscriber VCR type to all of the "subscriber" field de- 
vices on the bus 34 when the publisher device receives 
a compel data message from the LAS or from a sub- 
scriber device. The publisher/subscriber relationships 
are predetermined and are defined and stored within the 
Fieldbus access sublayer of the communication stack 
of each field device. 

[0067] To assure proper communication activities 
over the bus 34, each LAS periodically sends a time dis- 
tribution message to all of the field devices connected 
to a segment of the bus 34, which enables the receiving 
devices to adjust their local application time to be in syn- 
chronization with one another. Between these synchro- 
nization messages, clock time is independently main- 
tained in each device based on its own internal clock. 
Clock synchronization allows the field devices to time 
stamp data throughout the Fieldbus network to indicate, 
for example, when data was generated. 
[0068] Furthermore, each LAS (and other link master 
device) on each bus segment stores a "live list," which 
is a list of all the devices that are connected to that seg- 
ment of the bus 34, i.e., all of the devices that are prop- 
erly responding to a pass token message. The LAS con- 
tinually recognizes new devices added to a bus segment 
by periodically sending probe node messages to ad- 
dresses that are not on the live list. In fact, each LAS is 
required to probe at least one address after it has com- 
pleted a cycle of sending pass token messages to all of 
the field devices in the live list. If a field device is present 
at the probed address and receives the probe node 
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message, the device immediately returns a probe re- 
sponse message. Upon receiving a probe response 
message, the LAS adds the device to the live list and 
confirms by sending a node activation message to the 
probed field device. A field device remains on the live , 5 
list as long as that field device responds properly to pass 
token messages. However, an LAS removes a field de- 
vice from the live list if the field device does not, after 
three successive tries, either use the token or immedi- 
ately return the token to the LAS. When a field device is 10 
added to or removed from the live list, the LAS broad- 
casts changes in the live list to all the other link master 
devices on the appropriate segment of the bus 34 to al- 
low each link master device to maintain a current copy 
of the live list. J 5 
[0069] As noted above, the communication intercon- 
nections between the field devices and the function 
blocks thereof are determined by a user and are imple- 
mented within the process control network 10 using a 
configuration application located in, for example, the 20 
host 12. However, after being configured, the process 
control network 10 operates without any consideration 
for device or process diagnostics and, therefore, inter- 
faces with the host 1 2 to perform standard I/O functions, 
but not diagnostic functions. 25 
[0070] When a user wishes to perform diagnostics, 
the user may have the host 12 send set point changes 
to, for example, the AO function block 63 of the control 
LOOP1 and record feedback in the AO function block 
63 using a trend object associated with the AO function 30 
block 63. However, to perform this type of communica- 
tion, the host 12 must use asynchronous (non-pub- . 
lished) communications which allow the host 12 access 
to the bus 34 only when the host 1 2 receives a pass 
token message from an LAS. As a result, the different 35 
parts of the diagnostic signal generated by the host 12 
may not reach the AO function block 63 at precisely de- 
termined times (or precisely scheduled times) which 
means that the diagnostic signal received at the AO 
function block 63 will have a shape that is, at least in *o 
part, determined by the communications backlog on the 
bus 34 at any particular time. For this reason, any diag- 
nostic signal sent using asynchronous communications 
will not be strictly deterministic and, thus, may not be 
very effective in performing diagnostics on a device or *s 
a process. Furthermore, the host 1 2 has no way of guar- 
anteeing that the feedback data collected by the trend 
object(s) will not be lost due to overwrites, etc. Also, the 
host 12 has no way of controlling the mode of the other 
function blocks in LOOP1, such as the PID function so 
block 64, without specifically changing the mode of that 
block. 

[0071] Until now. in order to assure complete and 
strictly deterministic diagnostics in a process, a user had 
to take the process control network 10 off-line and 55 
reconfigure the communication interfaces therein so 
that the host 12 was able to send set point changes to 
the appropriate devices and receive data measured by 



appropriate devices via synchronous communications. 
However, as noted above, this procedure shuts the 
process down and requires that an operator reconfigure 
the process control network whenever diagnostics are 
to be performed, both of which are undesirable. Further- 
more, the control implemented by the host 1 2 during this 
diagnostic procedure is different than the control being 
implemented by the communicatively linked function 
blocks during normal operation of the process and, 
therefore, collected process data may not be indicative 
of the operation of the process while the process is being 
controlled normally. 

[0072] To overcome these disadvantages in, for ex- 
ample, a Fieldbus process control network, a device or 
process diagnostic procedure is stored in and imple- 
mented from a field device and may be used to perform 
device and/or process diagnostics on that device or us- 
ing that device. The diagnostic procedure, which may 
be implemented as a function block, is configured to 
communicate with function blocks or other components 
of the device in which it is located and of receiving data, 
such as measurements of device parameters or other 
process parameters, over, for example, the bus 34 using 
synchronous periodic communications (e.g., the pub- 
lisher/subscriber VCR of Fieldbus protocol). In this man- 
ner, the diagnostic routine is capable of deterministically 
controlling the device in which it is located and of receiv- 
ing and storing data pertaining to a device or a process 
parameter in a periodic manner. 

[0073] Referring to now to Fig. 6, a schematic block 
diagram illustrates the digital field device 16 (of Fig. 3) 
which is a two-wire, loop-powered, two-way digitally- 
communicating positioner/valve combination. The digit- 
al field device 16 includes a field device controller 102, 
an l/P transducer 104, a pneumatic relay 106, an actu- 
ator 108, and a valve 109, which are interconnected by 
various pneumatic and electrical lines. 
[0074] The field device 1 6 receives operating signals 
and transmits status information and data in digital form 
via the two-wire bus segment 34b, preferably according 
to the Fieldbus standard, and is, therefore, a two-wire 
positioner. Similarly, the field device 16 receives power, 
primarily for driving the device controller 102 and the I/ 
P transducer 104, via the two-wire continuous loop bus 
segment 34b and is, therefore, a loop-powered device. 
[0075] As illustrated in Fig. 6, the l/P transducer 104 
is electrically connected to the device controller 1 02 by 
an l/P transducer control line 110 and, in the illustrated 
embodiment, communicates with the device controller 
102 using analog control signals. 
[0076] The l/P transducer 1 04 generates a pneumatic 
signal that causes actuation of the valve 1 09 and is high- 
ly useful in electromechanical devices for converting 
electrical signals to air pressure for a pneumatic posi- 
tioner. The actuator 108 controls the position of a valve 
member 114 (which may be a valve stem) of the valve 
109 while a position sensor 116 senses the position of 
the valve member 114 and generates a feedback signal 
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that is communicated to the device controller 102 via a 
signal line 117. This position signal may be used by the 
device controller 102 to control the operation of the field 
device 1 6 so that the l/P transducer 1 04 drives the pneu- 
matic pressure in.a manner that causes the valve mem- 
ber 114 to be at a desired position. Position and other 
feedback information may be stored in a storage unit or 
a memory of the device controller 1 02 and externally ac- 
cessed via the bus 34. 

[0077] As is standard, the field device 16 receives a 
supply of pressurized air from an external source (not 
shown) via a pneumatic line 118 connected to the l/P 
transducer 1 04 and to the pneumatic relay 1 06. An input 
sensor 1 20 typically positioned between the external air 
source and the l/P transducer 104 measures the input 
pneumatic supply pressure in the pneumatic line 118 
and delivers this measurement to the device controller 
102. The l/P transducer 104 is connected to the pneu- 
matic relay 106 via a pneumatic control line 122 and an 
l/P sensor 124 is positioned between the l/P transducer 
104 and the pneumatic relay 106 to measure the pneu- 
matic supply pressure in the line 122. Likewise, the 
pneumatic relay 106 is connected to the actuator 108 
via a pneumatic actuation line 126 and a relay sensor 
128 is positioned between the pneumatic relay 106 and 
the actuator 1 08 to measure the pneumatic supply pres- 
sure in the line 126. The pneumatic lines 118, 122 and 
126 are considered parts of a single pneumatic line in- 
terconnecting the transducer 104 and the valve 109. 
[0078] During operation, the device controller 102 
controls actuation of the vaive 109 by controlling the I/ 
P transducer 104 to set a controlled valve operating 
pressure in the pneumatic control line 126. The device 
controller 1 02 sends a control signal to the l/P transduc- 
er 104 via the l/P transducer control line 110 to control 
an output pressure of the l/P transducer 104 and relay 
106 combination to be between about 3-100 psi 
(0.21-7.06 kscm) which is applied to a control input of 
the actuator 108. The actuator 108 generates an output 
pressure that is applied to operate the valve 109. 
[0079] Thus, as is known, the l/P transducer 1 04 con- 
verts electrical signals into a pneumatic air pressure sig- 
nal. One example of a suitable l/P transducer 1 04 is de- 
scribed in U.S. Patent No. 5,439,021, entitled "Electro- 
Pneumatic Converter," issued to B. J. Burlage et al, on 
August 8, 1995. Likewise, the pneumatic relay 106, 
which serves as a pneumatic amplifier, is controlled by 
the J/P transducer 104 as directed by the device con- 
troller 1 02 to increase the air pressure of the pneumatic 
actuation signal line 126 a controlled amount. Thus, 
generally speaking, the pneumatic relay 106 supplies a 
controlled output pressure to a load or utilization device, 
such as an actuator or a piston, in response to a control 
signal from the device controller 102. A suitable relay is 
described in U.S. Patent No, 4,974,625, entitled "Four 
Mode Pneumatic Relay," issued to S. B. Paullus et al, 
on December 4, 1 990. In the illustrated embodiment, the 
relay 106 is a multi-functional four-mode pneumatic re- 



lay that is configurable for any combination of direct/ 
snap, direct/proportional, reverse/snap, or reverse/pro- 
portional operation. In the proportional mode, the pneu- 
matic relay 106 develops a pressure output that is pro- 

, 5 portional to a pressure or force input. In an on/off or snap 
mode, the pneumatic relay 1 06 generates a constant 
pressure output, usually equal to the pressure of the ap- 
plied supply, in response to the application of a defined 
range of force or pressure control inputs. In a direct 

10 mode of operation, the output pressure of the pneumatic 
relay 106 increases with an increasing input signal. In a 
reverse mode of operation, the relay output pressure de- 
creases with an increasing input signal. 
[0080] The input sensor 120, the l/P sensor 124, and 

15 the relay sensor 1 28 are pressure transducers that con- 
tain a pressure-to-electrical signal converter for convert- 
ing a pressure signal to an electrical signal and supply 
feedback signals to the device controller 102 via a line 
130. The l/P sensor 124 is diagnostically useful for de- 

20 tecting failure of either the l/P transducer 104 or the 
pneumatic relay 106 and determining, for example, 
whether a failure is a mechanical failure or an electrical 
failure. The l/P sensor 124 is also useful for detecting 
some system problems including a determination of 

25 whether the air pressure input to the digital field device 
16 is sufficient. As a result, the l/P sensor 124 allows 
the status of the l/P transducer 104 and the pneumatic 
relay 1 06 to be rapidly diagnosed so that these devices 
can be replaced quickly, if necessary. , 

30 [0081] In one embodiment, a suitable valve 109 for 
use in the digital field device 16 is a valve and actuator 
assembly using a spring and diaphragm actuator on a 
sliding stem valve which is used in an analog device de- 
scribed in U.S. Patent No. 4,916,144, entitled "Diagnos- 
es tic Apparatus and Method for Fluid Control Valves," is- 
sued to W. V. Fitzgerald, on December 11,1 990. In this 
exemplary embodiment, a pressure signal of about 3 psi 
(0.21 kscm) is provided to the actuator 108 in response 
to an approximate 4 mA signal applied by the device 

40 controller 102 to the l/P transducer 104, resulting in a 
corresponding pressure in the pneumatic actuation sig- 
nal line 126 that is insufficient to move the valve 109 
from a fully opened position. If the field device controller 
1 02 changes the control current applied to the l/P trans- 

^5 ducer 104 to approximately 20 mA, the l/P transducer 
104 generates a pressure in the pneumatic actuation 
line 1 26 of approximately 1 5 psi (1 .06 kscm), which forc- 
es the valve 109 to a fully closed position. Various po- 
sitions of the valve 109 between the fully opened posi- 

50 tion and the fully closed position are attained through 
the operation of the device controller 102 controlling the 
input current applied to the l/P transducer 104 in the 
range from 4 mA to 20 mA. 

[0082] The device controller 102 performs relatively 
55 high-speed digital communications to receive control 
signals and to transmit position and pressure informa- 
tion to an external processor or workstation in the proc- 
ess control network 10 via the bus 34. The device con- 



13 



25 



EP 0 929 850 B1 



26 



troller 102 includes storage or memory for stoxing the 
results of multiple diagnostic tests so that pertinent data 
are available for analysis. Diagnostic operations, such 
as device diagnostics, are generally in the form of soft- 
ware program codes and are typically encoded, stored 
and executed in the device controller 102 of the field 
device 16 in combination with program codes executing 
in an external device such as a processor or the host 
workstation 1 2. 

[0083] A device diagnostic evaluation of the valve 1 09 
may be performed through the operation of the device 
controller 1 02 controlling the input current applied to the 
l/P transducer 104 in a range sufficient to test the valve 
109 between fully opened and fully closed positions. 
During the device diagnostic evaluation, the outputs of 
the input sensor 120, the l/P sensor 124, and the relay 
sensor 128 are monitored by the device controller 102 
to sense the pneumatic pressure in the pneumatic lines 
1 1 8, 1 22 and 1 26, respectively, which are used for anal- 
ysis. The output of the position sensor 116 is also mon- 
itored to detect position or movement of the valve stem 
114 which corresponds to a position of or motion of a 
valve plug (not shown) within the valve 109. 
[0084] Thus, a test operating cycle of the valve 1 09 is 
performed under control of the device controller 102 by 
applying a controlled variable current to the l/P trans- 
ducer 104, sensing the pressure within the pneumatic 
lines 118, 122 and 126 and sensing the position of the 
valve stem 114 using the position sensor 116. In this 
manner, the device controller 102 simultaneously re- 
ceives time-varying electrical signals indicating the 
pressures at the illustrative locations and the position of 
the valve 109 and may used these signals to determine 
any number of device diagnostic parameters in any 
known or desired manner. 

[0085] Conventional field devices typically do not in- 
clude a position sensor, such as the sensor 116, and do 
not use position sensor results for diagnostic evalua- 
tions. Also, conventional field devices do not include 
sensors such as the input sensor 120, the l/P sensor 
124, and the relay sensor 128 for measuring pressure 
in the pneumatic control and for converting the pressure 
signal to an electrical signal to facilitate diagnostic eval- 
uation. However, these sensors and, particularly, the I/ 
P sensor 124, improve diagnostic capabilities by facili- 
tating localization of failure, error or fault conditions in 
the field device 16. In particular, the l/P sensor 124 as- 
sists in differentiation between failures of the valve 1 09, 
other failures in the field device 1 6, and failtues external 
to the field device 1 6 including failures of pneumatic line 
feeding the field device 16. The l/P sensor 124 is also 
useful for performing a diagnostic test to determine the 
operational status of the l/P transducer 104, the pneu- 
matic relay 1 06, the field device 1 6 and the process con- 
trol system 10 in general. In one embodiment, the l/P 
transducer 104 and the pneumatic relay 106 are tested 
using a diagnostic test procedure that drives the l/P 
transducer 1 04 full open to measure the full air pressure 



provided to the valve 1 09. While the l/P transducer 1 04 . 
is driven open, the l/P sensor 124 constantly measures 
pressure in the pneumatic control line 122. If the pres- 
sure begins to decrease, the test indicates that the air 

5 supply may be insufficient. A further diagnostic test of 
air supply sufficiency is performed by pumping the valve 
1 09 by applying an oscillating signal to the l/P transduc- 
er 1 04 so that the valve 1 09 begins a suction action with 
respect to the air supply and then measuring maximum 

10 flow and maximum pressure values using the l/P sensor 
124. 

[0086] As illustrated in Fig. 7, the device controller 
102 includes a microprocessor 140, an interface 142, a 
bus isolation circuit 144, a plurality of storage devices 

15 such as a random access memory (RAM) 146, a read- 
only memory (ROM) 148 and a nonvolatile random-ac- 
cess memory (NVRAM) 150, and a plurality of signal 
processing devices such as an A/D converter 152, a D/ 
A converter 154 and a multiplexer 156. The interface 

20 142 (which is a bus connector) is a circuit that performs 
serial to parallel protocol conversion and parallel to se- 
rial protocol conversion and is used to add framing in- 
formation to data packets according to any desired pro- 
tocol definition, such as the Fieldbus protocol. The bus 

25 isolation circuit 144 is a circuit that is used to convert a 
two-wire media communication signal on the bus 34 to 
a digital representation of the communication signal and 
supplies power received from the bus 34 to other circuits 
in the device controller 102 as well as to the l/P trans- 

30 ducer 104. The bus isolation circuit 144 may also per- 
form wave-shaping and signaling on the bus 34. 
[0087] The A/D converter 152 is connected to trans- 
ducers such as the position and pressure transducers 
of the position sensor 116 and the pressure sensors 

35 1 20, 1 24 and 1 28 of Fig. 6 as well as to any other desired 
analog input devices. Although the A/D converter 152 
may have a limited number of input channels, the mul- 
tiplexer 1 56 may be used to allow multiple signals to be 
sampled. If desired, the multiplexer 156 may include a 

40 bank of amplifiers connected between the signal lines 
117 and 130 (Fig. 6) to amplify the position, pressure 
and other feedback signals delivered thereto. The D/A 
converter 154 performs digital to analog conversion on 
signals developed by the microprocessor 140 to be de- 

45 livered to analog components, such as the l/P transduc- 
er 104. 

[0088] In a typical diagnostic test application, the con- 
troller 1 02 generates a 0-30 mA output test signal to the 
l/P transducer 1 04 in, for example, a programmed ramp, 

50 step change, on/off form (or in any other desired man- 
ner) to operate the valve 109 over a predetermined 
range of pneumatic pressures, and receives diagnostic 
test output signals developed by the pressure input sen- 
sor 120, the l/P sensor 124, the relay sensor 128 and 

55 the position sensor 116. Specific test procedures may 
be specified at and are generally initiated externally to 
the field device 16 using an input/output device such as 
a workstation, although the procedures (and necessary 
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information associated therewith) may also be input di- 
rectly to the controller 102, using an input device such 
as a keyboard. If desired, however, the test procedures 
may be stored in the controller 1 02. Similarly, diagnostic 
test result information collected by or produced in the ,5 
field device controller 102 is typically transferred to an 
external input/output device, although such information 
may also be directly displayed from the device controller 
102 using, for example, a CRT display or a printer. 
[0089] The field device 16 performs diagnostic test 10 
operations, such as device and process diagnostics, us- 
ing a program language interpreter embedded within the 
controller 1 02 that interprets commands such as those 
requesting the performance of diagnostic process 
steps. The language interpreter is preferably imple- is 
mented in a program code stored in the PROM 1 48 and 
executes in the microprocessor 140. In some embodi- 
ments, a test (diagnostic) definition or procedure is en- 
coded into the PROM 148 and, thus, preloaded into the 
field device 16. In other embodiments, a test (diagnos- 20 
tic) definition or procedure is downloaded at or before 
the time that the procedure is to be run and is stored in, 
for example, the RAM 146 for execution by the micro- 
processor 140. In a typical embodiment, some diagnos- 
tic functions are hard-coded into the PROM 1 48 and oth- 25 
er functions are downloaded, allowing the design and 
implementation of new diagnostic tests without modify- 
ing the permanent or hard-coded software in the device 
1 6. Although the language interpreter is described with- 
in the context of the performance of process diagnostics 30 
or device diagnostics in a Fieldbus-type device (such as 
a Fieldbus valve), the language interpreter may be im- 
plemented in any type of embedded controller, thereby 
enabling the use of common diagnostic test operations 
in any other type of embedded controller. 35 
[0090] During operation, the field device 16 receives 
instructions via the bus 34 from an operator console or 
host workstation 12 in the process control network 10. 
The language interpreter executing in the device con- 
troller 102 interprets the instructions and executes the *o 
operations defined by the instructions. In an illustrated 
embodiment, the language definition is depicted in a Us- 
er Interface Command Table shown in TABLE 1 , as fol- 
lows: 



TABLE 1 



Command 


Parameters) 


Move Absolute 


Position 


Move Relative 


Offset 


Pause 


Time 


Set Increment 


Increment 


Increment UP 




Increment Down 




Loop Start 


Number of Iterations 



50 
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TABLE 1 (continued) 



Command 


Parameters) 


Loop End 




Stop 




Data Rate 


Integer Multiple of Servo Rate 


//Comment Line 




Label: 




Call Subroutine 


Subroutine Name 


Return 




Test Variable 


Variable, Value, Address 



[0091] In this diagnostic language specification, a us- 
er can use a command name to specify the command 
for execution. A comment line is any line that begins with 
two slashes (//), according to the standard C/C+ + con- 
vention. A label is any word followed by a colon. 
[0092] A diagnostic test procedure may be defined in 
an operator console such as in the host 12 which gen- 
erates a sequence of instructions in accordance with the 
language definition designed to implement the diagnos- 
tic test procedure. The operator console then transmits 
the sequence of instructions encoded in the interpretive 
language via the bus 34 to the digital field device 16 us- 
ing, for example, asynchronous communications in the 
Fieldbus protocol. The language interpreter executing 
in the device controller 102 stores the received instruc- 
tions and interprets the instructions sequentially to con- 
trol the valve 1 09 as directed by the instructions to there- 
by preform the diagnostic test. Diagnostic test proce- 
dures may, for example, control the field device 16 to 
repeatedly step the valve 109, move the valve 109 up 
or down, move the valve 109 a selected amount in a 
selected direction, and the like. The diagnostic test pro- 
cedure also controls the collection of data from sensors 
in the field device 1 6 (as well as from other devices) and 
controls transmission of data to the control console or 
host workstation 1 2 via the bus 34. Of course, if desired, 
the diagnostic test procedures implemented by instruc- 
tions provided to the controller 102 may also process 
the received data to determine diagnostic results and 
may send these results to the host 1 2 or to other display 
device. 

[0093] Thus, the diagnostic language interpreter with- 
in the device controller 1 02 controls operation of the field 
device 16 according to programmed instructions to en- 
able diagnostic test procedures to be defined external 
to the digital field device 16 so that diagnostic tests may 
be defined and modified freely without modification of 
the field device 1 6. Likewise, new diagnostic control pro- 
cedures may be developed and sent to the field device 
1 6 afterthe field device 1 6 has been installed in the proc- 
ess control network 10. If desired, however, the device 
16 may also or alternatively implement device and/or 
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process diagnostic test instructions stored in the device 
at the time of manufacture or at some other time. 
[0094] A control console (such as the host 1 2) typical- 
ly includes diagnostic development tools such as lan- 
guage editors and simulators for developing the control 5 
routines in the diagnostic language for execution by the 
field device 16. The control console also typically in- 
cludes analysis tools for analyzing data received from 
the field device 16 via the bus 34. 

[0095] For the sake of completeness, example diag- io 
nostic program codes in an interpretive language are il- 
lustrated as follows for controlling the valve 109: 

Program Code 

(1) SAMA Static Test Definition 

[0096] //CYCLE 0 TO 100% 3 TIMES 
DataRate 1 

CYCLE:Loop3 20 

Move Absolute 0.0 

Pause 10000 

Move Absolute 100.0 

Pause 10000 

LoopEnd 25 
//MOVE TO 50% STEP UP 4 TIMES 
Move Absolute 50.0 
Pause 10000 
Setlncrement 10.0 

UP:LOOP4 30 
Increment Up 
Pause 10000 
LoopEnd 

//STEP DOWN 8 TIMES 

DOWN: Loop 8 35 

IncrementDown 

Pause 1 0000 

LoopEnd 

//STEP UP 4 TIMES 

UP2:Loop 4 40 

IncrementUp 

Pause 10000 

LoopEnd 

Stop 

45 

(2) Step Change Test Definition 

[0097] DataRate 1 
MoveAbsolute 50.0 

Pause 10000 50 
MoveAbsolute 60.0 
Pause 10000 
Stop 

(3) Stepped Ramp Test Definition 55 

[0098] DataRate 1 
MoveAbsolute 50.0 



Setlncrement 0.5 

//STEP UP BY 0.5 FOR 10 TIMES 

UP1:Loop10 

IncrementUP 

Pause 1000 

LoopEnd 

//STEP DOWN BY 0.5 FOR 10 TIMES 

DOWN1: Loop 10 

IncrementDown 

Pause 1000 

LoopEnd 

Setlncrement 1.0 

//STEP UP BY 0.5 FOR 10 TIMES 

UP2:Loop10 

IncrementUp 

Pause 1000 

LoopEnd 

//STEP DOWN BY 0.5 FOR 10 TIMES 

DOWN2: Loop 10 

IncrementDown 

Pause 1000 

LoopEnd 

Setlncrement 2.0 

//STEP UP BY 0.5 FOR 1 0 TIMES 

UP3:Loop10 

IncrementUp 

Pause 1000 

LoopEnd 

//STEP DOWN BY 0.5 FOR 10 TIMES 

DOWN3:Loop10 

IncrementDown 

Pause 1000 

LoopEnd 

stop 

(4) Step Study Test Definition 
[0099] DataRate 1 

//STEP UP, DOWN, DOWN, UP, THEN INCREMENT 
STEP SIZE AND 

//REPEAT UNTIL CHANGES DETECTED. 

Setlncrement 0.5 

IncrementUp 

Pause 100 

IncrementDown 

Pause 100 

IncrementDown 

Pause 100 

Increment Up 

Pause 100 

Setlncrement 1.0 

IncrementUp 

Pause 100 

IncrementDown 

Pause 100 

IncrementDown 

Pause 100 

IncrementUp 
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Pause 100 
Setlncrement 2.0 
IncrementUp 
Pause 100 
IncrementDown 
Pause 100 
IncrementDown 
Pause 100 
IncrementUp 
Pause 100 
Setlncrement 5.0 
IncrementUp 
Pause 100 
IncrementDown 
Pause 100 
IncrementDown 
Pause 100 
IncrementUp 
Pause 1 00 
Stop 

[0100] The first above-identified test (1) cycles three 
times, performs four steps from the half open position, 
steps down eight times and steps up four times. The 
second test (2) performs a step change from 50 to 60 
percent of the absolute position of the valve. The third 
test (3) performs three cycles of a stepped ramping 
waveform starting at 50 percent of the absolute position 
of the valve. The fourth test (4) repeats a series of steps 
with increasing magnitudes until a change in the valve 
is detected. 

[0101] In these routines, the field device controller 
102 implements a Conditional pause to stop recording 
and sets a bit in a storage location to indicate where a 
test is stopped. The field device controller 102 also im- 
plements a Branch/GOTO statement, a Loop forever 
statement, and a forced stop when an out-of-service flag 
is set. The pauses are synchronized with servo run 
times to that the test does not get out of synch with the 
valve. 

[0102] The illustrative program code depicts only 
some examples of the types of diagnostic tests that may 
be executed by the field device 16, there being many 
other diagnostic tests that may be performed by pro- 
gram instructions provided to the field device 16 includ- 
ing, for example, a static cycle test in which the valve 
109 is moved 10% up, 10% down, 10% up, 10% down, 
and so on for a plurality of cycles. Likewise, any device 
diagnostic measurements may be made including, for 
example, simple measurements of valve travel or pres- 
sures within the device 16 as developed by the sensors 
116, 120, 124 and 128 and/or any desired parameters 
derived from these or other measurements including, for 
example, (1) a dynamic error band, which is a plot of 
travel (e.g., the output of the position sensor 1 1 6) versus 
input (e.g., the control signal delivered to the controller 
102), (2) a plot of the drive signal (which is the output of 
the controller 1 02 as delivered to the l/P transducer 1 04) 
versus a pressure measurement, (3) a plot of drive sig- 



nal versus input signal, (4) output signal, which is plot, 
of travel versus drive signal, (5) valve signature, which 
is plot of pressure versus travel, etc. Of course the pres- 
sure signals specified in these tests may be any desired 
5 pressure signals, such as those measured by any of the 
sensors 120, 124 and/or 128. 

[0103] Although the diagnostic language and diag- 
nostic language interpreter is advantageously imple- 
mented in a process control network 10 using Fieldbus 
10 communications for communicating to a digital field de- 
vice 1 6 in the form of a two-wire, loop-powered, two-way 
digitally-communicating positioner, the language inter- 
preter may be implemented in other embodiments. For 
example, the diagnostic language interpreter may be 
15 implemented in any embedded controller that commu- 
nicates using any desired communication technology 
such as digital, analog, optical and the like. Further- 
more, although the illustrated diagnostic language inter- 
preter communicates according to the Fieldbus stand- 
ee ard protocol, alternative embodiments of the diagnostic 
language interpreter may be implemented in an embed- 
ded controller that communicates using other commu- 
nication protocols including, for example, the HART, 
Profibus, etc. protocol and in systems that uses other 
25 than two-wire buses, such as systems that use four-wire 
buses. Likewise, the diagnostic language interpreter 
may be implemented and used in other types of valves 
including, for example, electronic and hydraulic valves, 
as well as in other types of devices besides valve devic- 
30 es. 

[0104] Moreover, although the diagnostic language 
and diagnostic language interpreter are described as 
defining a particular instruction set, other instruction 
sets may be implemented according to the specifica- 

35 tions of the embedded controller within which the lan- 
guage and interpreter are defined. 
[01 05] Of course, both device and process diagnostic 
tests may be performed by issuing a command request- 
ing one or more specific diagnostic test procedures at 

40 an operator console such as the host workstation 1 2. In 
the illustrated embodiment, the diagnostic test proce- 
dures are implemented in two software program codes. 
A first code executes in a processor external to the field 
device 16, for example, in the host workstation 12, to 

45 create or initiate a diagnostic test and to receive collect- 
ed data and perform analysis thereon, while a second 
code executes in the device controller 102 to implement 
a diagnostic test stored therein or provided by the host 
12 in the form of program instructions. In contrast, diag- 

50 nostics in a conventional control system network are 
performed solely by software executing in a processor 
of a control console. Many advantages are gained by 
executing diagnostic tests at the field device level rather 
than at a control console level. For example, diagnostic 

55 testing may be performed in parallel and may be distrib- 
uted among many field devices by executing these tests 
at the device level. Likewise, a more accurate test may 
be performed in process control networks having dis- 
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tributed control functions, such as in the Fieldbus pro- 
tocol, where a host may not be able to deterministically 
control operation of the field device due to the fact that 
the host must communicate with the field device in an 
asynchronous manner to perform a diagnostic test. 
[01 06] Implementation of the two-way digital-commu- 
nication defined by the Fieldbus protocol is highly ad- 
vantageous for improving the speed of diagnostics, both 
through an increase in data throughput and by facilitat- 
ing parallel performance of diagnostics among a plural- 
ity of field devices. Using the Fieldbus protocol, regularly 
scheduled messages are transferred at prescheduled 
times and unscheduled messages, including diagnostic 
messages and data, calibration information and other 
information such as status indications, are transferred 
when the messages or data are ready and the field de- 
vice bus 34 is not otherwise busy. Diagnostic request 
messages are received by target field devices and di- 
agnostic tests are performed by the field devices asyn- 
chronously with respect to operations of other field de- 
vices. When a diagnostic test operation is complete, a 
field device returns a response, such as result data, 
when the field device bus 34 is available. Accordingly, 
as noted above* a plurality of field devices may perform 
diagnostic tests in parallel. 

[0107] Referring now to Fig. 8, a flow chart 200 illus- 
trates a technique for performing diagnostic tests within 
the field device 16. At a step 202, the field device 16 
receives a request to perform a sequence of instructions 
implementing one or more diagnostic tests. Of course, 
the host workstation 12 may issue such requests to any 
one or to a multiplicity of field devices simultaneously 
and allow each field device to collect diagnostic data in 
parallel. If a multiplicity of field devices are performing 
tests simultaneously, the workstation 12 may collect da- 
ta over an extended time interval as rapidly as the diag- 
nostic tests are performed and the results are made 
available on the bus 34 by the individual field devices. 
Conventional devices using a unique set of wires to 
communicate with each field device only access a single 
field device at one time and only perform a single test 
for the single field device at one time. 
[0108] At a step 204, the field device 16 performs a 
series of instructions to implement the one or more di- 
agnostic tests as directed by the request. Of course, as 
noted above, the instructions may be stored in the mem- 
ory of the field device 1 6 or may be provided to the field 
device by the host 12 via, for example, asynchronous 
communications. While the test is being implemented, 
one or more parameters such as valve travel, pressure, 
etc. are measured in parallel. Thus, while conventional 
field devices typically receive a command for a single 
diagnostic test measurement, perform the measure- 
ment serially, and respond to the request with a single 
measurement value due to the limited communication 
bandwidth and the lack of storage capability in these 
field devices, the field device 16 may receive a request 
for a plurality of tests using a flexible test protocol, may 



perform the plurality of tests, and then respond with the 
results collected during the tests. 
[0109] At a step 206, the field device 16 stores para- 
metric results of the plurality of tests measured for each 

5 of the diagnostic tests in a memory and, at a step 208, 
transmits the data to the external requesting device. 
Two-wire, two-way digital communication in accordance 
with the Fieldbus standard substantially improves the 
test result throughput of the digital field device 16. In 

10 fact, digital communications using Fieldbus protocol im- 
proves data transmission time by approximately thirty 
times over HART systems so that, when the Fieldbus 
protocol is used to perform diagnostic tests on multiple 
field devices in parallel, the amount of diagnostic test 

15 time for a process control network including many field 
devices is greatly reduced. 

[01 1 0] While conventional field devices typically have 
a separate pair of wires connecting each field device to 
a network so that each field device has exclusive access 

20 to the wires, in the illustrated embodiment, results of the 
diagnostic tests are transmitted to the operator console 
or the host workstation 12 over the bus 34 using the 
Fieldbus standard protocol which reduces the amount 
of wire required to communicate with the host 12. 

25 [01 1 1] As will be understood, during a diagnostic test 
procedure, the microprocessor 140 controls the D/A 
converter 1 54 to supply a varying control signal to the M 
P transducer 1 04. For each particular control signal val- 
ue and sample time, the microprocessor 104 directs the 

30 a/D converter 152 to measure the pressure and/or po- 
sition related electrical signals developed by the sen- 
sors 1 1 6, 1 20, 1 24 and 1 28 (as well as any other signals 
from other sensors). As the microprocessor 104 directs 
. the field device controller 102 through an operating 

35 measurement cycle, pressure and valve travel informa- 
tion are accessed by the device controller 102 and are 
processed or stored. The collected data is often tempo- 
rarily stored in the RAM 146 and is communicated to an 
external device, such as a host workstation 1 2, often for 

40 subsequent processing, analysis and display. Of 
course, the microprocessor 140 may also perform anal- 
ysis if desired. 

[0112] For example, pressure information measured 
by the relay sensor 128 and position information meas- 

45 ured by the position sensor 116 may be analyzed in 
combination to determine the change in valve dia- 
phragm pressure as a function of valve position. Simi- 
larly, pressures measured by the input sensor 120. the 
l/P sensor 124 and the relay sensor 128 may each be 

50 analyzed in combination with the position measured by 
the position sensor 116 to generate a deviation cycle 
showing a complete analysis of the operation of the 
valve 109 including characteristics of linearity, hystere- 
sis and range. 

55 [0113] Referring to Fig. 9, a flow chart 300 illustrates 
a diagnostic test protocol implemented in the field de- 
vice 16 to perform a diagnostic test. An operator gener- 
ates a sequence of diagnostic instructions at an opera- 
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tor console such as the workstation 1 2 and transmits the 
diagnostic instructions to the field device 16 which 
stores these instructions in memory. Alternatively, or in 
addition, diagnostic instructions may be stored in the 
memory of the field device 1 6 during manufacture of the 5 
device. 

[0114] At a step 302, the field device 16 receives a 
diagnostic command via the field device bus 34. If de- 
sired, the diagnostic command may be in the form of 
instructions in an interpretive diagnostic language en- 
coded for execution in the field device controller 102 or 
may be an instruction to initiate instructions already 
stored within the device 16. The device controller 102 
executes the various instructions to cause control ele- 
ments in the digital field device 1 6 such as the l/P trans- 
ducer 104 and the actuator 108 to manipulate the valve 
109 and to cause sensors such as the input sensor 120, 
the l/P sensor 1 24, the relay sensor 1 28 and the position 
sensor 116 to perform measurements. The control in- 
structions may also include instructions for processing 
the measurements and formatting data for presentation 
to a user. Additional instructions may cause the field de- 
vice controller 1 02 to send processed or formatted data 
to the requester via the field device bus 34. 
[0115] At a step 304, the digital field device 16, upon 
request, performs a test procedure in which, for exam- 
ple, the valve 109 is exercised from a full-ciosed status 
to full-open, then back to a full-closed status. Likewise, 
the digital field device 16 may, upon request, perform a 
plurality of step tests including, for example, a single 
step movement and analysis, and a ten-step movement 
and response measurement. A stepped ramp test may 
be also be used and involves a series of steps from a 
slight opening to a large opening of the valve, such as 
a ramp ranging from 1 0% to 90% in steps of, for exam- 
ple, 10% increments. A stepped study involves opening 
the valve in predefined steps, such as 1 %, 2%, 5% and 
1 0%, moving the valve in a first direction a specified step 
size, stabilizing, and then moving the valve in a second 
direction at the specified step size. 
[0116] At a step 306, the physical configuration of a 
diagnostic test is set by commands communicated to 
the digital field device 16. The physical configuration 
variables include a drive signal applied to the actuator 
108, a pressure setting applied to the l/P transducer 
104, as well as actuator pressure and a valve travel 
reading. The physical configuration variables may be 
set as independent test variables in some diagnostic 
tests and monitored as dependent parameters in other 
tests. 

[0117] At a step 308, the field device 16 measures 
predetermined parameters for a particular physical test 
configuration. For many diagnostic tests, multiple pa- 
rameters are measured for a single test configuration. 
Typical parameters that are measured using a single 
test configuration include valve position, process varia- 
ble, actuator air pressure, supply pressure, drive signal, 
transducer set point and l/P air pressure, to allow deter- 



mination of, for example, valve signature, output signal, 
dynamic error band, drive versus pressure, and travel 
versus input signal amplitude. 

[0118] At a step 310, the field device 16, through the 
operation of the device controller 102, stores the multi- 
ple parameters for a single test configuration in, for ex- 
ample, the RAM 146. At a step 312, the data is commu- 
nicated to the host 1 2 or other device. If testing is to be 
performed using a different diagnostic test configura- 
tion, the field device 1 6, through the operation of the de- 
vice controller 102 in a conditional step 314, loops back 
to the step 306 to modify the test configuration. 
[0119] The diagnostic tests in the illustrated field de- 
vice 1 6 are substantially improved in comparison to con- 
vention field devices in part through improvements in the 
diagnostic protocol structure, in part through improve- 
ments in communication, and in part through the imple- 
mentation of additional sensors in the field device 16. 
The improvements in diagnostic protocol structure ena- 
ble the field device 16 to measure multiple parameters 
for a single test configuration. The distribution of diag- 
nostic control operations to the field devices enable di- 
agnostic tests to be completely controlled, upon re- 
quest, within a field device so that multiple requests may 
be made to multiple field devices with the individual field 
devices controlling the diagnostic tests independently 
and in parallel to one another. The improvements in di- 
agnostic protocol structure also advantageously enable 
the test procedures to be modified external to the field 
device by programming changes. Accordingly, new di- 
agnostic capabilities may be added and wholesale 
changes in diagnostic operations may be made without 
modifying the field device. Modification of a field device 
is highly disadvantageous due to the tremendous ex- 
pense of shutting down a process line. The improve- 
ments in communication enable the field device 16 to 
measure multiple parameters for a single test configu- 
ration. Conventional field devices receive a request on 
communication lines that are dedicated to a specific field 
device, set a test configuration according to the specifi- 
cations of the request, and return a single test measure- 
ment according to the request. A subsequent measure- 
ment under the same test configuration is made by re- 
peating the step, including the redundant step of setting 
the test configuration. The improved communications of 
the illustrated field device 16 advantageously allow di- 
agnostic testing of multiple devices in parallel, increas- 
ing diagnostic test throughput. Furthermore, the im- 
proved digital communications provide for a plurality of 
data types where analog communications (of conven- 
tional field devices) do not. 

[0120] While the invention has been described with 
reference to various embodiments, it will be understood 
that these embodiments are illustrative and that the 
scope of the invention is not limited to them. Many var- 
iations, modifications, additions and improvements of 
the embodiments described are possible. For example, 
the field device 16 is but one illustration of a suitable 
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control valve and actuator combination. Other suitable 
valve types include sliding stem, rotary plug, rotary ball, 
butterfly, eccentric disk valves as well as other known 
valve types. Other suitable actuators include spring and 
diaphragm, spring and piston, double-acting piston, hy- 5 
draulic, electrohydraulic, electric or other known actua- 
tor types using either a rotary or sliding stem valve. 
Thus, the field device 16 is merely illustrative of various 
types of positioners or other devices for controlling an 
actuator and valve to modulate power. Moreover, the 10 
field device in which the diagnostics of the present in- 
vention are used or located can be a device other than 
a valve including, for example, a pump controller, a var- 
iable speed drive, etc. Still further, the field device 16 is 
not limited to operation in compliance with the Fieldbus '5 
standard but is further applicable to other digital com- 
munication standards including HART, WORLDFIP, 
LONWORKS, Profibus and the like. 
[0121] Of course, device and process diagnostic tests 
may be stored in the controller 102 in the form of function 20 
blocks or other software and may be made so that these 
diagnostic tests are accessible by the public using any 
host device, such as a personal computer, so that these 
tests may implemented without requiring much knowl- 
edge on the part of the user. In one embodiment, one 25 
or more easily accessible diagnostic routines are stored 
in the device (e.g., the device 16) and may be run by 
issuing a single command from a host specifying which 
test is to be run. All of the data necessary for the test is 
stored in the device and all output data collected for the 30 
test is sent to the host after the test is complete. 
[0122] Generally speaking, such "public" device and 
process diagnostics can be commanded to write to 
transducer blocks to effect movement of, for example, 
valve components, and to read and store data produced 35 
by the sensors using a trending block in the Fieldbus 
protocol. Because all of information required by the host 
is located in the device description of the field device, 
no proprietary knowledge is required to implement any 
of these public diagnostics. With the use of such public *o 
diagnostics, the operation of a field device may be com- 
pared with the operation of any other field device made 
by other manufacturers having the same diagnostics 
therein. 

[0123] Example waveforms used in such public diag- *5 
nostics are illustrated in Figs. 10A-10C. As indicated by 
Fig. 10A, a public diagnostic may cause the valve 109 
to move in a step-wise ramping manner in the opening 
direction at individual steps of, for example, one percent 
for a particular number of steps (e.g., five steps) and is so 
then moved in a step-wise ramping manner in the clos- 
ing direction at individual steps of one percent until the 
initial value or position of the valve has been reached. 
Preferably, a step to the new set point is instantaneous, 
i.e., no rate limits are in effect, and the delay time at each 55 
new set point is fixed and is determined by the size and 
response characteristics of the valve/actuator device. 
Alternatively, as indicated by Fig. 10B, a public diagnos- 



tic may move a valve through a ramp of five percent in 
the opening direction and then immediately move the 
valve through a ramp of five percent in the closing di- 
rection. The rate of the ramps are preferably fixed and 
set to a rate determined by the valve/actuator size. Most 
preferably, the ramp rate is approximately one-half of 
the maximum rate of the speed for the device. Moreover, 
as indicated by Fig. 10C, a public diagnostic may move 
a valve in the opening (or closing) direction in a single, 
for example, five percent step from the current valve po- 
sition, with the instantaneous step time set that so that 
no rate limits are in effect. This test concludes with the 
valve in a new valve baseline position five percent above 
(or below) the initial point. 

[01 24] To implement the public diagnostics illustrated 
in Figs. 10A-10C using the Fieldbus protocol, the host 
12 sends an execution command to the device storing 
the public diagnostics which sets a trend list in the de- 
vice (e.g., the device 16) and then sets an appropriate 
VCR in the device 16 for trending. Next, the link object 
of the device 16 is set for trending and, thereafter, the 
diagnostic test proceeds. At this time, the host may dis- 
play a message to the user indicating that the diagnos- 
tics are in process and the host may read the status or 
progress of the diagnostics to determine if an error con- 
dition occurs. After the device 1 6 has completed the di- 
agnostic, the host reads and stores the trended data and 
turns the trending off. The host may then perform anal- . 
ysis on the retrieved data. If a status pf, for example, 
200% or more is received from the device 1 6, an error 
in the diagnostics has occurred and the host may indi- 
cate such an error to the user. After analyzing the re- 
ceived data, the host may display the diagnostic data 
developed from the stored trends or any results deter- 
mined therefrom to the user. For example, the host 12 
may graphically depict the actual movement of the valve 
in response to one or all of the above-described, public 
diagnostic waveforms along with the input waveform to 
depict the response of the device 16 to the waveform. 
[01 25] When performing a public, or other diagnostic, 
the device 16 first determines if a diagnostic command 
signal has been received and, if so, verifies that the 
transducer block of the device is operating satisfactorily. 
If so, the device 1 6 then sets updated pointers for trend 
data to indicate which data should be stored in the trend 
block and verifies that a sufficient set point range is 
available to perform the diagnostic. For example, to run 
a test that requires five percent movement of the valve 
in the opening direction, the valve must be at or below 
95 percent of its maximum movement. If this range is 
not available, the device 16 may send back an error 
message to the host 12. 

[0126] If no error has occurred, the device 16 runs a 
selected test using test times and slope rates deter- 
mined from a lookup table (based on the valve/actuator 
size) stored in the device 16 and takes the desired 
measurements such as the position of the valve. During 
the test, the valve updates the test status with a percent 
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complete from 0-1 00 percent and, if an error is detected, 
writes an error code greater than 200 percent to a diag- 
nostic status variable which is read by the host 12. At 
the end of the test, assuming no errors have been 
reached, the diagnostic test writes a 1 00 percent status 5 
in the diagnostic test status variable and, thereafter, re- 
ports collected trend data to the host using normal stack 
operations set up to do the trending according to stand- 
ard Fieldbus protocols. Preferably, the loop speed of the 
diagnostic test is set to be relatively high as compared W 
to the changes within the input waveform so that enough 
• trend data is collected to adequately model the re- 
sponse of the device 16 to the diagnostic waveform. 
Thus, in a Fieldbus protocol, where the frequency of da- 
ta sampling in a trend object is tied to the execution rate 15 
of the function blocks, the loop execution rate should be 
much higher than the rate of changes within the input 
waveform to enable the trend object to collect enough 
data to observe the response of the device 1 6 to the 
input waveform after each significant change therein. 
[0127] Of course, the public diagnostics illustrated in, 
for example, Fig. 10, are best suited to perform device 
diagnostics, in that they can be advantageously used to 
cause a particular device to go through one or more di- 
agnostic steps or operations during which time the out- 25 
puts of transducers within the device are measured to 
determine characteristics of that device. When used in 
a Fieldbus protocol for device diagnostics, these tests 
do not require the use of any additional function blocks 
but, instead, can be run by an individual device control- 30 
ler (such as the controller 102 of Fig. 6) to control the 
transducer blocks apart from the normal operation as- 
sociated with the function blocks operating within the de- 
vice. Of course, if desired, a function block may be used 
to analyze the collected data in some manner and to 35 
provide the analyzed data to the host. 
[0128] Referring now to Fig. 11 A, a process control 
loop 400 capable of implementing device or process di- 
agnostics locally from a device in a Fieldbus process 
control network is illustrated in detail. The loop 400 in- <o 
eludes the control loop, LOOP1 of Fig. 4, having the Al 
function block 66 of the device 20 communicatively con- 
nected via the bus 34 with the PID function block 64 and 
the NO function block 63 both of the device 1 6. The loop 
400 also includes a data collection function block 401 45 
configured to receive data from the AO function block 
63, the Al function block 66 and, if desired, other function 
blocks such as Al function blocks 402 and 404, which 
may be located in other field devices connected within 
the process control network 10. Of course, the function 50 
blocks 66, 402 and 404 are configured to communicate 
with the data collection function block 401 using stand- 
ard synchronous communications, such as publisher/ 
subscriber communications defined within the Fieldbus 
protocol. 55 
[0129] During operation, the controller 102 within the 
field device 16 interrupts the normal operation of the 
loop formed by the function blocks 66, 64 and 63 and 



delivers a diagnostic waveform to the input of the AO. 
function block 63. At that time, the AO function block 63 
has its status mode changed to, for example, a local 
control mode, which cascades back to the PID function 
block 64 causing the PID function block 64 to shed its 
mode status to, for example, manual, which in turn pre- 
vents the PID function block 64 from producing an out- 
put signal based on the inputs received thereby. As not- 
ed above, the diagnostic waveform may be stored in the 
comroller 102 of the device 16 or may be provided by 
the host 1 2 prior to implementation of the diagnostic test. 
Of course, the waveform or other instructions cause the 
valve associated with the device 1 6 to go through a se- 
ries of movements associated with a device or a process 
diagnostic test. 

[0130] During a device diagnostic, the data collection 
function block 401 receives data from the AO function 
block 63 as well as data from other transducers within 
the device 16, such as transducers associated with po- 
sition sensors and/or any of the pressure sensors like 
those illustrated in Fig. 6. During a process diagnostic, 
the data collection function block 401 also or alternative- 
ly receives data related to process variables as devel- 
oped by the Al function blocks 66, 402, 404, as well as 
any other function blocks within the process control net- 
work 1 0. The data collection function block 401 may col- 
lect this data along with data pertaining to the timing and 
the magnitude of the diagnostic waveform delivered to 
the AO function block 63 and may store this data for fu- 
ture delivery to the host 12, where it may be processed 
and illustrated to a user. 

[0131] After the device or process diagnostic test is 
completed, the data collected by the function block 401 
is delivered to the host 1 2 and the controller 1 02 releas- 
es control of the AO function block 63 back to the PID 
function block 64 to return the loop comprising the 
blocks 66, 64 and 63 to normal operation. Of course, at 
this time, the status mode of the blocks 64 and 63 are 
returned to normal operation. 

[0132] It should be noted that, while the data collec- 
tion function block 401 does not necessarily require any 
scheduled synchronous execution time, the communi- 
cation interconnections of the function block 401 must 
be established when configuring the process control 
loop 400 and, therefore, these communication intercon- 
nections exist even when no diagnostic is running. In 
other words, when the data collection function block 401 
needs to have data published to it over the bus 34, it 
must be configured to receive that data (i.e., the data 
published by other devices) at the initialization of the 
process control network 10 to avoid reguiring a user to 
reconfigure the network 1 0 simply to perform diagnos- 
tics. However, as noted above, because the data collec- 
tion function block 401 will generally collect only process 
variable data that is already published on the bus 34 or 
will collect data generated internally within the device in 
which the data collection function block 401 is present, 
the operation of the data collection function block 401 
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will not generally add to the amount of synchronous 
communications on the bus 34 or require additional 
scheduled execution times for the process control net- 
work 1 0. If desired, however, the data collection function 
block 401 may be configured to receive data not usually , 5 
published on the bus, which requires that the publishing 
block be configured to publish that data at the start-up 
of the process control network 1 0. 
[0133] Referring now to Fig. 11 B, a process control 
loop 406 capable of implementing local diagnostics 10 
within a device in a Fieldbus process control network is 
illustrated in detail. Similar to the loop 400 of Fig. 11 A, 
the loop 406 includes the control loop, LOOP1 of Fig. 4, 
having the Al function block 66 of the device 20 com- 
municatively connected via the bus 34 with the PI D f unc- is 
tion block 64 and the A/O function block 63 both of the 
device 16. The loop 406 also includes a data collection 
function block 408 (located in the device 16) which op- 
erates essentially the same as the data collection func- 
tion block 401 except that it is configured only to receive 20 
data locally from, for example, the AO function block 63, 
the PID function block 64 or any other transducers or 
sensors within the device, such as pressor sensors, po- 
sition sensors; etc. The data collection function block 
408 is especially useful in performing device diagnostics 25 
where the required data is generated locally within a de- 
vice. Because, the block 408 does not need to receive 
data from the bus 34, it does not have to be configured 
initially at the start-up of the process control network. 
[0134] Of course, the data collection function blocks 30 
401 and 408 are only two ways of collecting diagnostic 
data within a process control device, there being many 
other methods of collecting such data in different types 
of process control networks and devices. For example, 
the data for a device or a process may be collected by 35 
other parasitic software located in a device that does not 
conform to the definition of a fieldbus function block. 
[0135] Referring now to Fig. 12, a flowchart 500 illus- 
trates steps performed by a typical process diagnostic 
using, for example, the loop 400 of Fig. 11. At a step 4 o 
502, a data collection setup is provided to the data col- 
lection function block 401 and other data necessary for 
a diagnostic test is delivered from a host (e.g., host 12) 
to the device 1 6 in which the diagnostic is to be execut- 
ed. Thereafter, the diagnostic is initialized by a user to 45 
cause the loop being tested to be isolated from the rest 
of the process control network. Upon initialization, the 
device 16 changes the status of the AO function block 
63 to, for example, a local control mode, which causes 
the PID function block 64 (or other upstream function so 
blocks) to change mode automatically according to 
Fieldbus control standards. Thereafter, a block 506 per- 
forms a diagnostic instruction stored within the memory 
of the device 16 and the data collection function block 
401 collects diagnostic and process data at the block 55 
508. A block 510 determines if the test is complete and, 
if not, returns control to the block 506 which performs 
the next diagnostic instruction. Of course, the next in- 



struction may be a repeat of the previous one causing, 
for example, a device to move in single direction until a 
limit has been reached. 

[01 36] The loop performed by the blocks 506, 508 and 
51 0 repeats until the test is complete or until some error 
has occurred or is detected at the block 510, at which 
time a block 512 ends the diagnostic test and a block 
514 restores normal operating status to, for example, 
the AO function block 63 which causes the PID function 
block 64 to again change its status and control the AO 
function block 63 according to normal control operation. 
[0137] The data collected by the data collection func- 
tion block 401 is provided to the host 1 2 which analyses 
and/or displays the data. If desired, analysis can be per- 
formed in the device 16 and the results of the analysis 
may be provided by the host 12 to a display unit for dis- 
play. 

[01 38] Using the device diagnostic method according 
to the present invention, the device 16 collects both de- 
vice and process data without requiring separate control 
by a host to implement or receive the data. Because the 
diagnostic is performed within a device and is controlled 
by the controller of that device instead of a separate host 
device, the timing of the test can be controlled precisely 
and data collected during a diagnostic test can be easily 
time aligned with the operation performed by the device 
to provide accurate correspondence between the test 
waveform and the results of the test. When implemented 
to perform a process diagnostic, the. data collection 
function block 401 of the loop 400 (or any similar loop 
having a data collection function block configured to col- 
lect data from one or more process control loops) can 
be used to target loop performance rather than just de- 
vice performance and can be used to indicate whether 
or not a valve is appropriate for a loop or if there are 
other issues with the loop that would limit its overall per- 
formance. Process and/or device testing may be imple- 
mented periodically without requiring a process to be 
shutdown or placed in a non-operating state. Of course, 
when the data collection function block 401 is configured 
to collect only data already published on the loop, it is 
limited by the control schedule as to the data that can 
be collected and used for diagnostics. 
[0139] Although the diagnostic functions have been 
described herein as performing diagnostics on or using 
a downstream AO function block 63 (which is an output 
function block), and as receiving inputs from and deliv- 
ering feedback to an upstream PID function block 64 
(which is a control function block) connected in a simple 
control loop configuration, the data collection function 
block 401 or other diagnostic function routine of the 
present invention can be used in conjunction with other 
output functions or function blocks and other control 
functions or function blocks as desired and can be im- 
plemented in control loops having configurations other 
than that illustrated in Fig. 11 . 

[0140] Moreover, while some of the diagnostics de- 
scribed herein have been implemented in the form of a 



22 



43 



EP 0 929 850 B1 



44 



Fieldbus "function block," it is noted that the diagnostics 
of the present invention can be implemented using other 
types of blocks, programs, hardware, firmware, etc., as- 
sociated with other types of control systems and/or com- 
munication protocols. In fact, while the Fieldbus protocol 5 
uses the term "function block" to describe a particular 
type of entity capable of performing a process control 
function, it is noted that the term function block as used 
herein is not so limited and includes any sort of device, 
program, routine, or other entity capable of performing io 
a process control function in any manner at distributed 
locations within a process control network. Thus, the di- 
agnostic function blocks described and claimed herein 
can be implemented in other process control networks 
or using other process control communication protocols 15 
or schemes (that may now exist or that may be devel- 
oped in the future) which do not use what the Fieldbus 
protocol strictly identifies as a "function block." 
[0141] Still further, while process and device diagnos- 
tics have been described herein as being used in per- 20 
forming diagnostics on (or using) positioner/valve devic- 
es, it is noted that these diagnostics can be performed 
on (or using) other types of devices, such as those hav- 
ing moveable elements like dampers, fans, etc. Like- 
wise, although the diagnostics described herein are 25 
preferably implemented in software stored in a process 
control device, they may alternatively or additionally be 
implemented in hardware, firmware, etc., as desired. If 
implemented in software, the diagnostics of the present 
invention may be stored in any computer readable mem- so 
ory such as on a magnetic disk, a laser disk, or other 
storage medium, in a RAM, ROM, EPROM, etc. of a 
computer, and the like. Likewise, this software may be 
delivered to a user or a device via any known or desired 
delivery method including, for example, over a commu- 35 
nication channel such as a telephone line, the internet, 
etc. 



Claims 

1. A field device (16) including diagnostic means for 
use in a process control network (10) as e.g. in a 
fieldbus system, having a plurality of devices 
(12-32) communicatively coupled by a two-wire, 45 
digital communication, loop powered bus (34), the 
field device including a connector interface (142) 
that connects to the bus (34) to enable digital com- 
munication over the bus (34), the field device further 
containing 50 
a memory (146,148,150) that stores a diagnostic 
test routine having a series of diagnostic test in- 
structions; 

a controller (102,140) that performs the said diag- 
nostic test instructions; 55 
a data collection unit (146,1 48, 1 50, 401 , 408) that 
collects diagnostic data generated during a diag- 
nostic test; 



characterized by 

a communication unit(144) that communicates the 
data over the bus (34) to another device, 
a diagnostic program language interpreter which is 
embedded within the controller (102), that interpret- 
er interpreting commands such as those requesting 
the performance of diagnostic process steps, the in- 
terpreter being preferably implemented in a pro- 
gram code stored in a ROM (148), and executes in 
a microprocessor (140). 

2. The field device of Claim 1 , further comprising a po- 
sitioner coupled to a valve (56, 109) having a move- 
able valve member (1 1 4) and wherein the diagnos- 
tic test instructions specify movement of the valve 
member (114). 

3. The field device of Claim 2, further including a po- 
sition sensor (55, 116) that senses the position of 
the moveable valve member (114) during the diag- 
nostic test and that delivers a position signal indic- 
ative of the valve member (114) position to the data 
collection unit. 

4. The field device of Claim 3, wherein the positioner 
includes a pneumatic pressure line (118) coupled to 
a current-to-pressure transducer and further includ- 
ing a pressure sensor (55, 120, 124, 128) coupled 
to the pneumatic pressure line (118) that senses the 
pressure in the pneumatic pressure line (118) and 
that delivers a pressure signal indicative of the pres- 
sure in the pneumatic pressure line (118) to the data 
collection unit. 

5. The field device of Claim 4, further including a pneu- 
matic relay coupled on the pneumatic pressure line 
(118) between the electrical to pneumatic transduc- 
er (1 04) and a valve (59, 1 09) and the pressure sen- 
sor (55, 120, 124, 128) is coupled to the pneumatic 
pressure line (118) between the electrical to pneu- 
matic transducer (104) and the pneumatic relay 
(106). 

6. The field device of Claim 4, further including a pneu- 
matic relay (106) coupled on the pneumatic pres- 
sure line (118) between the electrical to pneumatic 
transducer (1 04) and a valve (59, 1 09) and the pres- 
sure sensor (55, 120, 124, 128) is coupled to the 
pneumatic pressure line (118) between the pneu- 
matic relay (106) and the valve (59, 109). 

7. The field device of Claim 4, wherein the pneumatic 
pressure line (118) includes a pressure supply line 
(118) that is coupled to an input of the electrical to 
pneumatic transducer (104) and the pressure sen- 
sor (55, 120, 124, 128) is coupled to the pneumatic 
pressure supply line (118) to measure the pressure 
supplied to the input of the electrical to pneumatic 
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transducer (104). 

8. The field device of Claim 1 , wherein the controller 
(14, 102) includes a program language interpreter 
adapted to interpret a program language and , 5 
wherein the diagnostic test instructions are stored 

in the program language. 

9. The field device of Claim 8, wherein the communi- 
cation unit is adapted to receive the diagnostic test w 
instructions in the program language from a second 
one of the plurality of devices (12-32) via the bus 
(34) and to store the received diagnostic test in- 
structions in the memory. 

15 

10. The field device of Claim 1 , wherein the field device 
includes a member that is moveable in an opening 
and a closing direction and wherein the diagnostic 
test instructions cause the member to move through 

a stepwise ramp in the opening and in the closing 20 
directions. 

11. The field device of Claim 10, wherein the step-wise 
ramp includes steps equal to approximately one 
percent of a range of movement of the member. 25 

12. The field device of Claim 1 , wherein the field device 
includes a member that is moveable in an opening 
and a closing direction and wherein the diagnostic 
test instructions cause the member to move through 30 
a linear ramp in the opening and the closing direc- 
tions. 

1 3. The field device of Claim 1 2, wherein the diagnostic 
test instructions cause the member to move at a 35 
ramp rate equal to approximately one-half of the 
maximum rate of movement of the member. 

14. The field device of Claim 1 , wherein the field device 
includes a member that is moveable and wherein «o 
the diagnostic test instructions cause the member 

to move in a step. 

15. The field device of Claim 14, wherein the step has 

an amplitude of approximately five percent of a 4 $ 
movement range of the member. 

16. The field device of Claim 1, wherein the controller 
is a device controller and wherein the communica- 
tion unit receives the diagnostic test instructions so 
from a second one of the plurality of devices via the 
bus stores the received diagnostic test instructions 

in the memory. 

17. The field device of Claim 16, wherein the diagnostic 55 
test instructions are written in a program language 
and the device controller (14, 102) includes a pro- 
gram language interpreter that interprets the diag- 



nostic test instructions to perform the diagnostic, 
test. 

18. The field device of Claim 17, further comprising a 
positioner coupled to a valve having a moveable 
valve member and wherein the diagnostic test in- 
structions specify movements of the valve member. 

19. The field device of Claim 18, further including a po- 
sition sensor that senses the position of the valve 
member during the diagnostic test and that delivers 
a position signal indicative of the valve member po- 
sition to the data collection unit. 

20. The field device of Claim 19, wherein the positioner 
includes a pneumatic pressure line (118) coupled to 
a current-to-pressure transducer (104) and further 
including a- pressure sensor (55, 120, 124, 128) 
coupled to the pneumatic pressure line that senses 
the pressure in the pneumatic pressure line (118) 
and that delivers a pressure signal indicative of the 
pressure in the pneumatic pressure line (118) to the 
data collection unit. 

21. The field device of Claim 16, wherein the commu- 
nication unit is configured to communicate over the 
bus using a Fieldbus protocol. 

22. The field device of Claim 1 6, wherein the diagnostic 
test instructions implement a process diagnostic 
and the communication unit is adapted to receive 
data via the bus (34) pertaining to process variables 
measured by other ones of the plurality of devices 
(12-32). 

23. The field device of Claim 1 , wherein the memory 
stores a process diagnostic test routine having a se- 
ries of diagnostic test instructions to be implement- 
ed by the field device, wherein the controller is a 
device controller that performs the process diag- 
nostic test instructions stored in the memory to im- 
plement a process diagnostic test, wherein the data 
collection unit collects diagnostic data generated by 
the field device during the process diagnostic test 
and that receives further process diagnostic data 
from a second one of the plurality of devices via the 
bus and wherein the communication unit communi- 
cates the collected diagnostic data and the further 
process diagnostic data over the bus after the proc- 
ess diagnostic test is completed. 

24. The field device of Claim 23, wherein the commu- 
nication unit is configured to communicate over the 
bus using a Fieldbus communication protocol and 
wherein the data collection unit is a function block 
(50) configured to receive the further process diag- 
nostic data from the second one of the plurality of 
devices (12-32) over the bus (34). 
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25. The field device of Claim 23, wherein the function 
block (50) is configured to receive the further proc- 
ess diagnostic data over the bus (34) using syn- 
chronous communications. 

5 

i 

26. The field device of Claim 23, wherein the device 
controller (102) includes a mode handling unit that 
controls the mode of components within a process 
control loop performing the process diagnostic test. 

w 

27. The field device of Claim 1 , in a process control net- 
work (10), including a host (12) device that gener- 
ates commands and receives data, a plurality of 
field devices (16-22), and a bus (34) communica- 
tively interconnects the host device (12) and the plu- 15 
rality of field devices (16-22). 

28. The field device of Claim 27, wherein the diagnostic 
test routine is a process diagnostic test routine and 
the data collection unit receives process diagnostic 20 
data from a second one of the plurality of field de- 
vices (12-32) via the bus (34). 

29. The field device of Claim 27, wherein the controller 
(14, 102) includes a program language interpreter 25 
adapted to interpret a program language and 
wherein the diagnostic test instructions are stored 

in the program language. 

30. The field device of Claim 29, wherein the commu- 30 
nication unit is adapted to receive the diagnostic 
test instructions in the program language from the 
host (12) device via the bus (34) and to store the 
received diagnostic test instructions in the memory 
prior to implementation of the diagnostic test. 35 

31. The field device of Claim 27, wherein each of the 
plurality of field devices (12-32) is capable of per- 
forming a process control function and of commu- 
nicating on the. bus (34) using scheduled periodic <o 
communications and non-periodic communica- 
tions. 

32. The field device of Claim 27, wherein the one of the 
plurality of field devices (12-32) includes a member 45 
that is moveable in an opening and a closing direc- 
tion and wherein the diagnostic test instructions 
cause the member to move through a stepwise 
ramp in the opening and in the closing directions. 

50 

33. The field device of Claim 32, wherein the step-wise 
ramp includes steps equal to approximately one 
percent of a range of movement of the member. 

34. The field device of Claim 27, wherein the one of the 55 
plurality of field devices (12-32) includes a member 
that is moveable in an opening and a closing direc- 
tion and wherein the diagnostic test instructions 



cause the member to move through a linear ramp 
in the opening and the closing directions. 

35. The field device of Claim 34, wherein the diagnostic 
test instructions cause the member to move at a 
ramp rate equal to approximately one-half of the 
maximum rate of movement of the member. 

36. The field device of Claim 27, wherein the one of the 
plurality of field devices (12-32) includes a member 
that is moveable and wherein the diagnostic test in- 
structions cause the member to move in a step. 

37. The field device of Claim 36, wherein the step has 
an amplitude of approximately five percent of a 
movement range of the member. 

38. The field device of Claim 1 , further adapted to use 
the Fieldbus communication protocol and wherein 
the data collection unit is a data collection function 
block (401, 408). 

39. The field device of Claim 38, wherein the diagnostic 
test is a device diagnostic test and wherein the data 
collection function block collects data from the field 
device. 

40. The field device of Claim 38, wherein the diagnostic 
test is a process diagnostic test and wherein the da- 
ta collection function block collects at least part of 
the diagnostic data from a further field device via 
communications over the bus. 



Patentanspruche 

1. Feldgerat (16), das eine Diagnoseeinrichtung zur 
Verwendung in einem ProzeBsteuerungsnetz (10), 
wie beispielsweise ein Feldbussystem enthalt, das 
eine Vielzahl von Einrtchtungen (12 bis 32) auf- 
weist, die durch einen schleifengespeisten Digital- 
kommunikations-Zweidrahtbus (34) kommunizie- 
rend gekoppelt sind, wobei das Feldgerat eine Ver- 
binderschnittstelle (142) aufweist, die mit dem Bus 
(34) verbunden ist, urn Digitalkommunikation uber 
den Bus (34) zu ermdglichen, wobei das Feldgerat 
ferner folgendes enthalt: 

einen Speicher (146, 148, 150), der eine Dia- 
gnoseprufroutine speichert, die eine Serie von 
Diagnoseprufbefehlen aufweist; 

eine Steuerung (102, 140), die die genannten 
Diagnoseprufbefehle ausfuhrt; 

eine Datensammeleinheit (146, 148, 150, 401, 
408), die bei einer Diagnoseprufung erzeugte 
Diagnosedaten sammelt; 
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gekennzeichnet durch 

eine Kommunikationseinheit (144), die die Da- 
ten uber den Bus (34) zu einer anderen Einrich- 
tung ubermittelt, 

einen Diagnoseprogrammierspracheninterpre- 
tierer (144), der in die Steuerung (102) inte- 
griert ist, wobei der Interpretierer Befehle wie 
etwa diejenigen, die die Ausfuhrung von Dia- 
gnoseprozeBschritten verlangen, interpretiert, 
wobei der Interpretierer bevorzugt in einem 
Programmcode implementiert ist, der in einem 
ROM (148) gespeichert ist, und in einem Mikro- 
prozessor (140) ausgefuhrt wird. 

2. Feldgerat nach Anspruch 1 , das ferner einen Posi- 
tionierer aufweist, der mit einem Ventil (56, 1 09) ge- 
koppelt ist, das ein bewegliches Ventilelement (114) 
hat, und wobei die Diagnoseprufbefehle die Bewe- 
gung des Ventilelements (114) bezeichnen. 

3. Feldgerat nach Anspruch 2, das ferner einen Posi- 
tionssensor (55, 116) aufweist, der die Position des 
beweglicheri Ventilelements (114) bei der Diagno- 
seprufung erfaBt und der Datensammeleinheit ein 
Positionssignal liefert, das die Position des Ventil- 
elements (114) bezeichnet. 

4. Feldgerat nach Anspruch 3, wobei der Positionierer 
eine Druckluftleitung (118) aufweist, die mit einem 
Strom-Druck-MeBumformer gekoppelt ist, und fer- 
ner einen mit der Druckluftleitung (118) gekoppelten 
Drucksensor (55, 120, 124, 128) aufweist, der den 
Druck in der Druckluftleitung (118) erfaBt und der 
Datensammeleinheit ein Drucksignal liefert, das 
den Druck in der Druckluftleitung (118) bezeichnet. 

5. Feldgerat nach Anspruch 4, das ferner ein pneuma- 
tisches Relais aufweist, das mit der Druckluftleitung 
(118) zwischen dem Strom-Druck-MeBumformer 
(104) und einem Ventil (59, 109) gekoppelt ist, und 
wobei der Drucksensor (55, 120, 124, 128) mit der 
Druckluftleitung (118) zwischen dem Strom-Druck- 
MeBumformer (104) und dem pneumatischen Re- 
lais (106) gekoppelt ist. 

6. Feldgerat nach Anspruch 4, das ferner ein pneuma- 
tisches Relais (106) aufweist, das mit der Druckluft- 
leitung (118) zwischen dem Strom-Druck-MeBum- 
former (104) und einem Ventil (59, 109) gekoppelt 
ist, und wobei der Drucksensor (55, 120, 124, 128) 
mit der Druckluftleitung (118) zwischen dem pneu- 
matischen Relais (106) und dem Ventil (59, 1 09) ge- 
koppelt ist. 

7. Feldgerat nach Anspruch 4, wobei die Druckluftlei- 
tung (118) eine Druckzufuhrleitung (118) aufweist, 



die mit einem Eingang des StrorrvDruck-MeBum-. 
formers (104) gekoppelt ist, und der Drucksensor 
(55, 120, 124, 128) mit der Druckluftzufuhrleitung 
(118) gekoppelt ist, um den Druck zu messen, der 
5 dem Eingang des Strom-Druck-MeBumformers 
(104) zugefuhrt wird. 

8. Feldgerat nach Anspruch 1 , wobei die Steuerung 
(14, 102) einen Programmierspracheninterpretierer 
10 aufweist, der so ausgebildet ist, daB er eine Pro- 
gram miersprache interpretiert, und wobei die Dia- 
gnoseprufbefehle in der Programmiersprache ge- 
speichert sind. 

15 9. Feldgerat nach Anspruch 8, wobei die Kommunika- 
tionseinheit so ausgebildet ist, daB sie Diagnose- 
prufbefehle in der Programmiersprache von einer 
zweiten von der Vielzahl der Einrichtungen (12 bis 
32) uber den Bus (34) empfangt und die empfange- 

20 nen Diagnoseprufbefehle in dem Speicher spei- 
chert. 

10. Feldgerat nach Anspruch 1, wobei das Feldgerat 
ein Element aufweist, das in einer Offnungs- und 
25 einer SchlieBrichtung bewegbar ist, und wobei die 
Diagnoseprufbefehle bewirken, daB sich das Ele- 
ment durch eine Stufenrampe in der Offnungs- und 
der SchlieBrichtung bewegt. 

30 11. Feldgerat nach Anspruch 1 0, wobei die Stufenram- 
pe Stufen aufweist, die ungefahr gleich einem Pro- 
zent eines Bewegungsbereichs des Elements sind. 

12. Feldgerat nach Anspruch 1, wobei das Feldgerat 
35 ein Element aufweist, das in einer Offnungs- und 

einer SchlieBrichtung bewegbar ist, und wobei die 
Diagnoseprufbefehle bewirken, daB sich das Ele- 
ment durch eine lineare Rampe in der Offnungs- 
und der SchlieBrichtung bewegt. 

40 

13. Feldgerat nach Anspruch 12, wobei die Diagnose- 
prufbefehle bewirken, daB sich das Element mit ei- 
ner Rampengeschwindigkeit bewegt, die ungefahr 
gleich derhalben maximalen Bewegungsgeschwin- 

45 digkeit des Elements ist. 

14. Feldgerat nach Anspruch 1, wobei das Feldgerat 
ein Element aufweist, das bewegbar ist, und wobei 
die Diagnoseprufbefehle bewirken, daB sich das 

so Element in einer Stufe bewegt. 

15. Feldgerat nach Anspruch 14, wobei die Stufe eine 
Amplitude von ungefahr funf Prozent eines Bewe- 
gungsbereichs des Elements hat. 

55 

16. Feldgerat nach Anspruch 1, wobei die Steuerung 
eine Einrichtungssteuerung ist und wobei die Kom- 
munikationseinheit die Diagnoseprufbefehle von ei- 
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nem zweiten von der Vielzahl von Einrichtungen 
uber den Bus empfangt und die empfangenen Dia- 
gnoseprufbefehle in dem Speicher speichert. 

17. Feldgerat nach Anspruch 16, wobei die Diagnose- 
prufbefehle in einer Programmiersprache geschrie- 
ben sind und die Geratesteuerung (14, 102) einen 
Programmierspracheninterpretierer aufweist, der 
die Diagnoseprufbefehle interpretiert, urn die Dia- 
gnoseprufung auszufuhren. 

18. Feldgerat nach Anspruch 17, das ferner einen Po- 
sitionierer aufweist, der mit einem Ventil gekoppelt 
ist, das ein bewegliches Ventilelement hat, und wo- 
bei die Diagnoseprufbefehle Bewegungen des Ven- 
tilelements bezeichnen. 

19. Feldgerat nach Anspruch 18, das ferner einen Po- 
sitionssensor aufweist, der die Position des Ventil- 
eiements bei der Diagnoseprufung erfaBt und der 
Datehsammeieinheit ein Positionssignal liefert, das 
die Position des Ventilelements bezeichnet. 

20. Feldgerat nach Anspruch 19, wobei der Positionie- 
rer eine Druckluftleitung (118) aufweist, die mit ei- 
nem Strom-Druck-MeBumformer (104) gekoppelt 
ist, und ferner einen mit der Druckluftleitung gekop- 
pelten Drucksensor (55, 120, 124, 128) aufweist, 
der den Druck in der Druckluftleitung (118) erfaBt 
und der Datensammeleinheit ein Drucksignal lie- 
fert, das den Druck in der Druckluftleitung (118) be- 
zeichnet. 

21. Feldgerat nach Anspruch 16, wobei die Kommuni- 
kationseinheit so konfiguriert ist, daB sie uber den 
Bus unter Anwendung eines Fieldbus-Protokolls 
kommuniziert. 

22. Feldgerat nach Anspruch 16, wobei die Diagnose- 
prufbefehle eine ProzeBdiagnose implementieren 
und die Kommunikationseinheit so ausgebildet ist, 
daB sie uber den Bus (34) Daten empfangt, die Pro- 
zeBvariable betreffen, die von einem anderen von 
der Vielzahl der Einrichtungen (12 bis 32) gemes- 
sen werden. 

23. Feldgerat nach Anspruch 1 , wobei der Speicher ei- 
ne ProzeBdiagnoseprufroutine speichert, die eine 
Reihe von Diagnoseprufbefehlen hat, die von dem 
Feldgerat zu implementieren sind, wobei die Steue- 
rung eine Einrichtungssteuerung ist, die die in dem 
Speicher gespeicherten ProzeBdiagnoseprufbe- 
fehte ausfuhrt, urn eine ProzeBdiagnoseprufung zu 
implementieren, wobei die Datensammeleinheit 
Diagnosedaten sammelt, die von dem Feldgerat bei ■ 
der ProzeBdiagnoseprufung erzeugt werden, und 
weitere ProzeBdiagnosedaten von einer zweiten 
von der Vielzahl der Einrichtungen uber den Bus 



empfangt, und wobei die Kommunikationseinheit 
die gesammelten Diagnosedaten und die weiteren 
ProzeBdiagnosedaten uber den Bus ubermittelt, 
nachdem die ProzeBdiagnoseprufung abgeschlos- 
5 sen ist. 

24. Feldgerat nach Anspruch 23, wobei die Kommuni- 
kationseinheit so konfiguriert ist, daB sie uber den 
Bus unter Anwendung eines Fieldbus-Kommunika- 

io tionsprotokolls kommuniziert, und wobei die Daten- 
sammeieinheit ein Funktionsblock (50) ist, der so 
konfiguriert ist, daB er die weiteren ProzeBdiagno- 
sedaten von der zweiten von der Vielzahl der Ein- 
richtungen (12 bis 32) uber den Bus (34) empfangt. 

15 

25. Feldgerat nach Anspruch 23, wobei der Funktions- 
block (50) so konfiguriert ist, daB er die weiteren 
ProzeBdiagnosedaten uber den Bus (34) unter An- 
wendung von synchronen Kommunikationen emp- 

20 fangt. 

26. Feldgerat nach Anspruch 23, wobei die Geratesteu- 
ereinheit (102) eine Modushandhabungseinheit ist, 
die den Modus von Komponenten innerhalb einer 

25 ProzeBsteuerschleife steuert, die die ProzeBdia- 
gnoseprufung ausfuhrt. 

27. Feldgerat nach Anspruch 1 in einem ProzeBsteue- 
rungsnetz (10), das folgendes aufweist: eine Haupt- 

30 rechnereinrichtung (12), die Befehle erzeugt und 
Daten empfangt, eine Vielzahl von Feldgeraten (16 
bis 22) und einen Bus (34), der die Hauptrechner- 
einrichtung (12) und die Vielzahl von Feldgeraten 
(16 bis 22) kommunikativ miteinander verbindet. 

35 

28. Feldgerat nach Anspruch 27, wobei die Diagnose- 
pruf routine eine ProzeBdiagnoseprufroutine ist und 
die Datensammeleinheit ProzeBdiagnosedaten 
von einem zweiten von der Vielzahl Feldgeraten (12 

40 bis 32) uber den Bus (34) empfangt. 

29. Feldgerat nach Anspruch 27, wobei die Steuerung 
(14, 102) einen Programmierspracheninterpretierer 
aufweist, der so ausgebildet ist, daB er eine Pro- 

45 grammtersprache interpretiert, und wobei die Dia- 
gnoseprufbefehle in der Programmiersprache ge- 
speichert sind. 

30. Feldgerat nach Anspruch 29, wobei die Kommuni- 
50 kationseinheit so ausgebildet ist, daB sie die Dia- 
gnoseprufbefehle in der Programmiersprache von 
der Hauptrechnereinrichtung (12) uber den Bus 
(34) empfangt und die empfangenen Diagnosepruf- 
befehle in dem Speicher speichert, bevor die Dia- 

55 gnoseprufung implementiert wird. 

31. Feldgerat nach Anspruch 27, wobei jedes von der 
Vielzahl von Feldgeraten (12 bis 32) imstande ist, 
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eine ProzeBsteuerungsfunktion auszufuhren und 
auf dem Bus (34) unter Anwendung von planmaBi- 
gen periodischen Kommunikationen und nichtperi- 
odischen Kommunikationen zu kommunizieren. 

32. Feldgerat nach Anspruch 27, wobei das eine von 
der Vielzahl von Feldgeraten p 2 bis 32) ein Ele- 
ment aufweist, das in einer Offnungs- und einer 
SchlieBrichtung bewegbar ist, und wobei die Dia- 
gnoseprufbefehle bewirken, daB sich das Element 
durch eine Stufenrampe in der Offnungs- und der 
SchlieBrichtung bewegt. 

33. Feldgerat nach Anspruch 32, wobei die Stufenram- 
pe Stufen aufweist, die ungefahr gleich einem Pro- 
zent eines Bewegungsbereichs des Elements sind. 

34. Feldgerat nach Anspruch 27, wobei das eine von 
der Vielzahl von Feldgeraten (12 bis 32) ein Ele- 
ment aufweist, das in einer Offnungs- und einer 
SchlieBrichtung bewegbar ist, und wobei die Dia- 
gnoseprufbefehie bewirken, daB sich das Element 
durch eine lineare Rampe in der Offnungs- und der 
SchlieBrichtung bewegt. 

35. Feldgerat nach Anspruch 34, wobei die Diagnose- 
prufbefehle bewirken, daB sich das Element mit ei- 
ner Rampengeschwindigkeit bewegt, die ungefahr 
gleich derhalben maximalen Bewegungsgeschwin- 
digkeit des Elements ist. 

36. Feldgerat nach Anspruch 27, wobei das eine von 
der Vielzahl von Feldgeraten (12 bis 32) ein Ele- 
ment aufweist, das bewegbar ist, und wobei die Dia- 
gnoseprufbefehle bewirken, daB sich das Element 
in einer Stufe bewegt. 

37. Feldgerat nach Anspruch 36, wobei die Stufe eine 
Amplitude von ungefahr funf Prozent eines Bewe- 
gungsbereichs des Elements hat. 

38. Feldgerat nach Anspruch 1 , das ferner zur Anwen- 
dung des Fieldbus-Kommunikattonsprotokolls aus- 
gebildet ist und wobei die Datensammeleinheit ein 
Datensammelfunktionsblock (401, 408) ist. 

39. Feldgerat nach Anspruch 38, wobei die Diagnose- 
prufung eine Geratediagnoseprufung ist und wobei 
der Datensammelfunktionsblock Daten von dem 
Feldgerat sammelt. 

40. Feldgerat nach Anspruch 38, wobei die Diagnose- 
prufung eine ProzeBdiagnoseprufung ist und wobei 
der Datensammelfunktionsblock mindestens einen 
Teil der Diagnosedaten von einem weiteren Feld- 
gerat uber Kommunikationen uber den Bus sam- 
melt. 



Revendications 

1. Dispositif de terrain (16) comprenant des moyens 
de diagnostic destines a etre utilises dans un h§- 
seau de commande de processus (10) tel que, par 
exemple, dans un systeme de bus de champ, com- 
portant une plurality de dispositifs (12 a 32) couples 
de maniere communicante par un bus de commu- 
nication num6rique & deux fils alimente en boucle 
(34), le dispositif de terrain comprenant une inter- 
face de connecteur (142) qui se connecte au bus 
(34) pour permettre une communication numdrique 
sur le bus (34), le dispositif de terrain contenant en 
outre 

une memoire (146, 148, 150) qui memorise 
une routine de test de diagnostic comportant une 
serie destructions de test de diagnostic ; 

un controleur (1 02, 1 40) J qui execute lesdites 
instructions de test de diagnostic ; 

une unite d'acquisition de donn6es (1 46, 1 48, 
150, 401, 408) qui collecte des-donnees de dia- 
gnostic generees pendant un test de diagnostic ; 

caracterise par 

une unite de communication (144) qui com- 
munique les donnees sur le bus (34) a un autre dis- 
positif, 

un interpreter de langage de programmation 
de diagnostic qui est integre dans le controleur 
(102), cet interpreter interpretant des comman- 
des. telles que celles demandant ['execution d'eta- 
pes de processus de diagnostic, I'interpreteur etant, 
de preference, mis en oeuvre dans un code de pro- 
gramme memorise dans une memoire morte (148), 
et s'execute dans un microprocesseur (140). 

2. Dispositif de terrain selon la revendication 1, com- 
prenant en outre un positionneur couple a une van- 
ne (56, 109) comportant un element de vanne mo- 
bile (114) et dans lequel les instructions de test de 
diagnostic sp6cif ient un mouvement de l'6lement de 
vanne (114). 

3. Dispositif de terrain selon la revendication 2, com- 
prenant en outre un detecteur de position (55, 116) 
qui detecte la position de I'element de vanne mobile 
(114) pendant le test de diagnostic et qui delivre un 
signal de position indicatif de la position de I'ele- 
ment de vanne (114) a I'unite d'acquisition de don- 
nees. 

4. Dispositif de terrain selon la revendication 3, dans 
lequel le positionneur comprend une ligne de pres- 
sion pneumatique (118) couplee a un transducteur 
courant-pression et comprenant, en outre, un de- 
tecteur de pression (55, 120, 124, 128) couple a la 
ligne de pression pneumatique (118) qui detecte la 
pression dans la ligne de pression pneumatique 
(118) et qui delivre un signal de pression indicatif 
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de la pression dans la ligne de pression pneumati- 
que (118) a I'unite d'acquisition de donnees. 

5. Dispositif de terrain selon la revendication 4, com- 
prenant en outre un relais pneumatique couple sur ( 
la ligne de pression pneumatique (118) entre le 
transducteur electrique-pneumatique (104) et une 
vanne (59, 109), et le detecteur de pression (55, 
120, 124, 128) est couple a la ligne de pression 
pneumatique (11 8) entre le transducteur electrique- 
pneumatique (104) et le relais pneumatique (106). 

6. Dispositif de terrain selon la revendication 4, com- 
prenant en outre un relais pneumatique (106) cou- 
ple sur la ligne de pression pneumatique (11 8) entre 
le transducteur electrique-pneumatique (104) et 
une vanne (59, 109), et le detecteur de pression 
(55, 1 20, 1 24, 1 28) est couple a la ligne de pression 
pneumatique (118) entre le relais pneumatique 
(1 06) et la vanne (59, 1 09). 

7. Dispositif de terrain selon la revendication 4, dans 
lequel la ligne de pression pneumatique (1 1 8) com- 
prend une ligne d'alimentation en pression (118) qui 
est couplee a une entree du transducteur electri- 
que-pneumatique (104) et le detecteur de pression 
(55, 120, 124, 128) est couple a la ligne d'alimen- 
tation en pression pneumatique (1 1 8) pour mesurer 
la pression appliquee a I'entree du transducteur 
electrique-pneumatique (104). 

8. Dispositif de terrain selon la revendication 1 , dans 
lequel le controleur (1 4, 1 02) comprend un interpre- 
teur de langage de programmation adapte pour in- 
terpreter un langage de programmation et dans le- 
quel les instructions de test de diagnostic sont me- 
morisees dans le langage de programmation. 

9. Dispositif de terrain selon la revendication 8, dans 
lequel I'unite de communication est adaptee pour 
recevoir les instructions de test de diagnostic dans 
le langage de programmation d'un deuxieme dispo- 
sitif de la pluralite de dispositifs (12 a 32) via le bus 
(34) et pour memoriserdans la memoire les instruc- 
tions de test de diagnostic regues. 

10. Dispositif de terrain selon la revendication 1, dans 
lequel le dispositif de terrain comprend un element 
qui est mobile dans un sens d'ouverture et dans un 
sens de fermeture et dans lequel les instructions de 
test de diagnostic provoquent le mouvement de 
I'element le long d'une rampe a paliers dans les 
sens d'ouverture et de fermeture. 

1 1 . Dispositif de terrain selon la revendication 1 0, dans 
lequel la rampe a paliers comprend des paliers ap- 
proximativement egaux a un pour cent d'une plage 
de mouvement de I'element. 



12. Dispositif de terrain selon la revendication 1, dans, 
lequel le dispositif de terrain comprend un 6l6ment 
qui est mobile dans un sens d'ouverture et dans un 
sens de fermeture et dans lequel les instructions de 

5 test de diagnostic provoquent le deplacement de 
I'element le long d'une rampe Iin6aire dans les sens 
d'ouverture et de fermeture. 

13. Dispositif de terrain selon la revendication 12, dans 
io lequel les instructions de test de diagnostic provo- 
quent le mouvement de I'element a une vitesse de 
rampe approximativement egale a la moitie de la 
vitesse maximum de mouvement de I'element 

15 14. Dispositif de terrain selon la revendication 1 , dans 
lequel le dispositif de terrain comprend un element 
qui est mobile et dans lequel les instructions de test 
de diagnostic provoquent le mouvement de I'ele- 
ment en un palier. 

20 

15. Dispositif de terrain selon la revendication 14, dans 
lequel le palier a une amplitude d'environ cinq pour 
cent d'une plage de mouvement de i'element. 

25 16. Dispositif de terrain selon la revendication 1 , dans 
lequel le controleur est un controleur de dispositif 
et dans lequel I'unite de communication regoit les 
instructions de test de diagnostic d'un deuxieme 
dispositif de la pluralite de dispositifs via le bus et 

30 memorise dans la memoire les instructions de test 
de diagnostic regues. 

1 7. Dispositif de terrain selon 1 a revendication 1 6, dans 
lequel les instructions de test de diagnostic sont 

35 ecrites dans un langage de programmation et le 
controleur de dispositif (14, 102) comprend un in- 
terpreter de langage de programmation qui inter- 
prete les instructions de test de diagnostic afin d'ef- 
fectuer le test de diagnostic. 

40 

18. Dispositif de terrain selon la revendication 17, com- 
prenant en outre un positionneur couple a une van- 
ne comportant un element de vanne mobile et dans 
lequel les instructions de test de diagnostic speci- 

45 fient des mouvements de I'element de vanne. 

19. Dispositif de terrain selon la revendication 18, com- 
prenant en outre un detecteur de position qui de- 
tecte la position de I'element de vanne pendant le 

50 test de diagnostic et qui delivre un signal de position 
indicatif de la position de I'element de vanne a I'uni- 
te d'acquisition de donnees. 

20. Dispositif de terrain selon la revendication 19, dans 
55 lequel le positionneur comprend une ligne de pres- 
sion pneumatique (118) couplee a un transducteur 
courant-pression (1 04) et comprenant, en outre, un 
detecteur de pression (55, 120, 124, 128) couple a 
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la ligne de pression pneumatique qui detecte la 
pression dans la ligne de pression pneumatique 
(118) et'qui dSlivre un signal de pression indicatif de 
la pression dans la ligne de pression pneumatique 
(118) a I'unite d'acquisition de donnees. 

21. Dispositif de terrain selon la revendication 16, dans 
lequel I'unite de communication est configure de 
maniere a communiquer sur le bus en utilisant un 
protocole de bus de champ. 

• 22. Dispositif de terrain selon la revendication 1 6, dans 
lequel les instructions de test de diagnostic mettent 
en oeuvre un diagnostic de processus et I'unite de 
communication est adaptee pour recevoir des don- 
nees via le bus (34) relatives a des variables de pro- 
cessus mesurees par d'autres dispositifs de la plu- 
rality de dispositifs (12 a 32). 

23. Dispositif de terrain selon la revendication 1 , dans 
lequel la memoire memorise une routine de test de 
diagnostic de processus comportant une serie 
destructions de test de diagnostic devant etre mi- 
ses en oeuvre par le dispositif de terrain, dans le- 
quel le controleur est un controleur de dispositif qui 
execute les instructions de test de diagnostic de 
processus memorisees dans la memoire afin de 
mettre en oeuvre un test de diagnostic de proces- 
sus, dans lequel I'unite d'acquisition de donnees 
collecte les donnees de diagnostic generees paMe 
dispositif de terrain pendant le test de diagnostic de 
processus, et qui regoit d'autres donnees de dia- 
gnostic de processus d'un deuxieme dispositif de la 
pluralite de dispositifs via le bus et dans lequel I'uni- 
te de communication communique les donnees de 
diagnostic acquises et les autres donnees de dia- 
gnostic de processus sur le bus une fois que le test 
de diagnostic de processus est achieve. 

24. Dispositif de terrain selon la revendication 23, dans 
lequel I'unite de communication est configuree de 
maniere a communiquer sur le bus en utilisant un 
protocole de communication de bus de champ et 
dans lequel I'unite d'acquisition de donnees est un 
bloc fonctionnel (50) configure de maniere a rece- 
voir les donnees de diagnostic de processus sup- 
piymentaires du deuxieme dispositif de la plurality 
de dispositifs (12 a 32) sur le bus (34). 

25. Dispositif de terrain selon la revendication 23, dans 
lequel le bloc fonctionnel (50) est configure de ma- 
niere a recevoir les autres donnees de diagnostic 
de processus sur le bus (34) en utilisant des com- 
munications synchrones. 

26. Dispositif de terrain selon la revendication 23, dans 
lequel le controleur de dispositif (102) comprend 
une unite de gestion de mode qui commande le mo- 



de des composants dans une boucle de commande 
de processus effectuant le test de diagnostic de 
processus. 

5 27. Dispositif de terrain selon la revendication i , dans 
un reseau de commande de processus (10), com- 
prenant un dispositif note (12) qui genera des com- 
mandes et regoit des donnees, une plurality de dis- 
positifs de terrain (1 6 a 22), et un bus (34) connecte 

10 le dispositif note (12) et la plurality de dispositifs de 
terrain (16 a 22) entre eux de maniere communi- 
cahte. 

28. Dispositif de terrain selon la revendication 27, dans 
15 lequel la routine de test de diagnostic est une rou- 
tine de test de diagnostic de processus et I'unite 
d'acquisition de donnees regoit des donnees de dia- 
gnostic de processus d'un deuxieme dispositif de la 
plurality de dispositifs de terrain (12 a 32) via le bus 

20 (34). 

29. Dispositif de terrain selon la revendication 27, dans 
lequel le controleur (14,1 02) comprend un interpre- 
ter de langage de programmation adapte pour in- 

25 terpreter un langage de programmation et dans le- 
quel les instructions de test de diagnostic sont me- 
morisees dans le langage de programmation. 

30. Dispositif de terrain selon la revendication 29, dans 
30 lequel I'unite de communication est adaptee pour 

recevoir les instructions de test de diagnostic dans 
le langage de programmation du dispositif note (1 2) 
via le bus (34) et pour memoriser dans la memoire 
les instructions de test de diagnostic regues avant 
35 la mise en oeuvre du test de diagnostic. 

31 . Dispositif de terrain selon la revendication 27, dans 
lequel chaque dispositif de la plurality de dispositifs 
de terrain (1 2 a 32) est capable d'executer une fonc- 

40 tion de commande de processus et de communi- 
quer sur le bus (34) en utilisant des communications 
periodiques pcogrammees et des communications 
non periodiques. 

45 32. Dispositif de terrain selon la revendication 27, dans 
lequel le dispositif de la plurality de dispositifs de 
terrain (12 a 32) comprend un element qui est mo- 
bile dans un sens d'ouverture et dans un sens de 
fermeture et dans lequel les instructions de test de 

50 diagnostic provoquent le mouvement de I'element 
le long d'une rampe a paliers dans les sens d'ouver- 
ture et de fermeture. 

33. Dispositif de terrain selon la revendication 32, dans 
55 lequel la rampe a paliers comprend des paliers ap- 
proximativement egaux a un pour cent d'une plage 
de mouvement de Telement. 
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34. Dispositif de terrain selon la revendication 27, dans 
lequel le dispositif de la pluralite de dispositifs de 
terrain (12 a 32) comprend un element qui est mo- 
bile dans un sens d'ouverture et dans un sens de 
fermeture et dans lequel les instructions de test de 5 
diagnostic provoquent le mouvement de I'element 

le long d'une rampe lineaire dans les sens d'ouver- 
ture et de fermeture. 

35. Dispositif de terrain selon la revendication 34, dans jo 
lequel les instructions de test de diagnostic provo- 
quent le mouvement de I'element a une vitesse de 
rampe approximativement egale a la moitte de la 
vitesse maximum de mouvement de I'element. 

36. Dispositif de terrain selon la revendication 27, dans 
lequel le dispositif de la pluralite de dispositifs de 
terrain (12 a 32) comprend un element qui est mo- 
bile et dans lequel les instructions de test de dia- 
gnostic provoquent le mouvement de I'element d'un 20, 
palier. 

37. Dispositif de terrain selon la revendication 36, dans 
lequel le palier a une amplitude d'environ cinq pour 
cent d'une plage de mouvement de I'element. 25 

38. Dispositif de terrain selon la revendication 1 , adapte 
en outre pour utiliser le protocole de communication 
de bus de champ et dans lequel I'unite d'acquisition 

de donnees est un bloc fonctionnel d'acquisition de 30 
donnees (401, 408). 

39. Dispositif de terrain selon la revendication 38, dans 
lequel le test de diagnostic est un test de diagnostic 

de dispositif et dans lequel le bloc fonctionnel d'ac- 35 
quisition de donnees collecte des donnees a partir 
du dispositif de terrain. 

40. Dispositif de terrain selon la revendication 38, dans 
lequel le test de diagnostic est un test de diagnostic *o 
de processus et dans lequel le bloc fonctionnel d'ac- 
quisition de donnees collecte au moins une partie 
des donnees de diagnostic a partir d'un autre dis- 
positif de terrain via des communications sur le bus. 
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